Richard Biener <richard.guent...@gmail.com> writes: > On Wed, May 11, 2022 at 2:23 PM Richard Sandiford via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: >> >> Wilco Dijkstra <wilco.dijks...@arm.com> writes: >> > Hi Richard, >> > >> >> Yeah, I'm not disagreeing with any of that. It's just a question of >> >> whether the problem should be fixed by artificially lowering the general >> >> rtx costs with one particular user (RA spill costs) in mind, or whether >> >> it should be fixed by making the RA spill code take the factors above >> >> into account. >> > >> > The RA spill code already works fine on immediates but not on address >> > constants. And the reason is that the current rtx costs for addresses are >> > set artificially high without justification (I checked the patch that >> > increased >> > the costs but there was nothing explaining why it was beneficial). >> >> But even if the costs are too high, the patch seems to be overcompensating. >> It doesn't make logical sense for an ADRP+LDR to be cheaper than an LDR. >> >> Giving X zero cost means that a sequence like: >> >> (set (reg x0) X) >> (set (reg x1) X) >> >> should stay as-is rather than be changed to: >> >> (set (reg x0) X) >> (set (reg x1) (reg x0)) >> >> I don't think we want that for multi-instruction constants when >> optimising for size. >> >> > It's certainly possible to experiment with increasing the spill costs, but >> > that >> > won't improve the issue with address constants unless they are at least >> > doubled. >> > And it has the effect of halving all rtx costs in the register allocator >> > which is >> > likely to cause regressions. So we'd need to adjust many rtx costs to keep >> > the >> > allocator working, plus fix any further regressions this causes. >> >> Yeah, I wasn't suggesting that we increase the spill costs. I'm saying >> that we should look at whether the target-independent RA heuristics need >> to change, whether new target hooks are needed, etc. We shouldn't go >> into this with the assumption that the target-independent code is >> invariant and that any fix must be in existing aarch64 hooks (rtx costs >> or spill costs). >> >> Maybe it would help to turn the question around for a minute. Can we >> describe the cases in which it's *better* for the RA to spill a constant >> address to the stack and reload it, rather than rematerialise on demand? > > From the discussion in PR102178 it seems that LRA cannot rematerialize > all "constants" (though here it is constant pool loads). Some constants > might also not be 'constant'. See the PR for more fun "spilling" behavior > on x86_64. > > It's also said that chosen alternatives might be the reason that > rematerialization > is not choosen and alternatives are chosen based on reload heuristics, not > based > on actual costs.
Thanks for the pointer. Yeah, it'd be interesting to know if this is the same issue, although I fear the only way of knowing for sure is to fix it first and see whether both targets benefit. ;-) Richard
