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] |
On 07/14/2010 09:03 PM, Jeff Law wrote:I've had patches like this (accumulating regs in the main reload loop and having them change on further iterations pessimizing code). They didn't trigger often, but fixing it was trivial, so why not? :-)
On 07/14/10 05:28, Bernd Schmidt wrote:Anecdotally, I seem to recall seeing this every now and then, and it's
How often have you seen this occur in practice? The complexity isAttached 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.
trivial, so if it's occuring with any regularity, I'd say go for it.
been bugging me for a while. Practically, in the last test run I think
it only affected one testcase out of the many I have collected for
comparing assembly output. I've added this code because one of the two
other changes made it show up.
* Use live_throughout sets to determine if a reload will forceGood point.Not really, it suffers from the same conceptual problem as the previousWell, you're detecting one of (many) cases where we know a particulara 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.)
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.
attempt I reverted. If we can't get completely accurate answers (and at
this point, we can't), it can happen that we prefer an alternative for
the wrong reasons (e.g. both of them will force a spill, but we can
prove it only for one of them here).
In practice it seems to work reasonably well, at least on ARM. MoreLet's hope others chime in.
testing would be good.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |