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: Patch: Revert find_reloads part of the IRA merge

On 07/14/10 05:28, Bernd Schmidt wrote:
I've now reverted the find_reloads change.

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

* When evaluating costs of alternatives, reload isn't taking into
account whether something is going to need secondary reloads.
I'm all for more accurate cost modeling.

* Use live_throughout sets to determine if a reload will force
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
reloads, etc.)
Well, 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.


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