This is the mail archive of the
mailing list for the GCC project.
Re: Patch: Revert find_reloads part of the IRA merge
- From: Jeff Law <law at redhat dot com>
- To: Bernd Schmidt <bernds at codesourcery dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, "Vladimir N. Makarov" <vmakarov at redhat dot com>, Richard Earnshaw <rearnsha at arm dot com>
- Date: Wed, 14 Jul 2010 13:03:01 -0600
- Subject: Re: Patch: Revert find_reloads part of the IRA merge
- References: <4C370373.email@example.com> <4C3D9F4C.firstname.lastname@example.org>
On 07/14/10 05:28, Bernd Schmidt wrote:
I've now reverted the find_reloads change.How often have you seen this occur in practice? The complexity is
trivial, so if it's occuring with any regularity, I'd say go for it.
Attached is a patch which tries to solve the problem in a different way;
I fixed some other problems that showed up in testing on ARM. Specifically:
* Immediately marking used_spill_regs as ever_live can cause a
situation where the next iteration will use a different set of
hard regs, and we end up pushing registers that are never used.
If we delay settings regs_ever_live until nothing else has
changed, we can avoid that, at the cost of a little bit of
complexity, and the risk of requiring more iterations. Not
sure this is worth it.
* When evaluating costs of alternatives, reload isn't taking intoI'm all for more accurate cost modeling.
account whether something is going to need secondary reloads.
* Use live_throughout sets to determine if a reload will forceWell, you're detecting one of (many) cases where we know a particular
reload is going to cause a spill. While it'd be nice to catch the other
cases, I don't think detecting all the cases where we can prove that a
reload is going to cause a spill is necessary. What you're proposing is
a clear incremental improvement IMHO.
a spill. This seems to work better than the previous heuristic,
but it can still fail (dead_or_set isn't taken into account
since it's quite a useless set, the test isn't run on address