This is the mail archive of the gcc-patches@gcc.gnu.org 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: IRA patch: use ORDER_REGS_FOR_LOCAL_ALLOC


On 04/27/2010 07:03 PM, Bernd Schmidt wrote:
On 04/28/2010 12:52 AM, Jeff Law wrote:
Well we no longer have a distinction between local& global allocation,
so ISTM that ORDER_REGS_FOR_LOCAL_ALLOC has been overtaken by events.
If you're getting better allocations with the patch then I would think
that you need to be defining REG_ALLOC_ORDER for the thumb differently.
That's the thing, there is only one way to define REG_ALLOC_ORDER since
it's an initializer.  If you need different ones depending on target
switches, as on ARM/Thumb, you need ORDER_REGS_FOR_LOCAL_ALLOC.  It's
just misnamed.  Even pre-IRA, it had an effect on both local and
global-alloc.

Yes, I think it is better to rename the macro, e.g. ORDER_REGS_FOR_ALLOC, because the current name is a misleading one.
WRT prologue/epilogue costs -- that's an ongoing discussion between Vlad
and myself -- there's definitely arguments for and against including
those costs and if they're going to be included whether or not the cost
should be scaled or not, how to account for the fact that the cost to
save/restore can be spread across multiple insns, etc etc. I don't
think we've reached any kind of definitive answer on this -- meaning
it'll probably be punted until we can do some extensive benchmarking
across several platforms.
As Jeff wrote, we had a discussion about this a few months ago. There are some pros and cons for the current solution. I made some SPEC2000 benchmarking and found that the current solution gives a bit better scores (but it was very small) for x86/x86_64.
What's there now is clearly wrong in some cases - e.g. on ARM, when
optimizing for size, once you save one register it doesn't cost anything
else to save more of them.

Should I add a new target macro that decides whether to ignore those costs?

Yes, probably introducing a new macro is a better solution.


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