This is the mail archive of the
mailing list for the GCC project.
Re: set_src_cost lying comment
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: law at redhat dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 24 Jun 2015 11:57:52 EDT
- Subject: Re: set_src_cost lying comment
- Authentication-results: sourceware.org; auth=none
- References: <20150622055710 dot GQ1723 at bubble dot grove dot modra dot org> <558A3AA9 dot 6090406 at redhat dot com> <20150624091846 dot GC1723 at bubble dot grove dot modra dot org> <558ACA63 dot 20608 at redhat dot com>
> These are good examples of things the costing model
> simply wasn't ever designed to consider -- because they weren't
> significant issues on the m68k, vax and other ports in the gcc-1 era.
> So I don't really know how to tell you to proceed -- I've considered the
> costing models fundamentally flawed for many years, but haven't ever
> tried to come up with something that works better.
I'm not sure I'd call it "fundamentally flawed" or that it wasn't
"designed to consider" these things. I see the costing model as meant
as a *heuristic* for making choices, not as a precise metric for
anything. Certainly, a lot of people worked on that model, including
both of us, during the gcc-2 RISC porting days.
I see the "flaw" as trying to use it for too much. There's a limit to
the amount of decisions you can make with purely local data. When
trying to decide whether a source should be a constant or a register,
you have to look at:
- the chances the reg-reg copy can be eliminated
- register pressure
- whether there's room to insn schedule around any conflicts
Unless you look at the whole picture, you're just guessing, which is, of
course, what a heuristic is all about!