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. Richard. > Thanks, > Richard
