This is the mail archive of the
mailing list for the GCC project.
Re: IRA patch: use ORDER_REGS_FOR_LOCAL_ALLOC
- From: Bernd Schmidt <bernds at codesourcery dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 28 Apr 2010 01:03:50 +0200
- Subject: Re: IRA patch: use ORDER_REGS_FOR_LOCAL_ALLOC
- References: <4BD70714.email@example.com> <4BD76ABC.firstname.lastname@example.org>
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
> 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.
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?