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?

Thanks,
Richard

Reply via email to