This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: set_src_cost lying comment

-----Original Message-----
From: [] On Behalf Of Richard Kenner
Sent: Wednesday, June 24, 2015 9:28 PM
Subject: Re: set_src_cost lying comment

> 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

Increasing or decreasing the cost of moves affects the Optimal Coalescing. Also the Live range splitting that generates the shuffle code
at the border if the registers in the partner live ranges are different/ Splitted live ranges where a partner has register and another partner
in memory, then a store would be needed otherwise a load is generated with respect to the live range has memory and the partner live
ranges in register then a load will be generated. All these conditions and heuristics are associated with move cost for x86 and other Architecture.

Thanks & Regards

>>Unless you look at the whole picture, you're just guessing, which is, of course, what a heuristic is all about!

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]