> 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!
