[PATCH] D118216: [RISCV] LUI used for address computation should not isAsCheapAsAMove

[Haocong Lu via Phabricator via llvm-commits]

Luhaocong added a comment.

In D118216#3305349 <https://reviews.llvm.org/D118216#3305349>, @jrtc27 wrote:

> In D118216#3305287 <https://reviews.llvm.org/D118216#3305287>, @craig.topper wrote:
>
>> In D118216#3305266 <https://reviews.llvm.org/D118216#3305266>, @jrtc27 wrote:
>>
>>> This seems conceptually wrong to me. isAsCheapAsAMove is meant to model how expensive an instruction is to execute, but how you compute the immediate it uses has zero bearing on that. `lui rd, 0x123` and `lui rd, %hi(sym)` if `%hi(sym)` happens to be 0x123 are completely indistinguishable from the perspective of the processor. To me this screams of something elsewhere getting cost modelling wrong.
>>
>> Maybe the heuristic #1 should ignore the isCheapAsMove if the instruction isTriviallyRematerializable?
>
> So the problem is that LUI _is_ current marked as cheap as a move, since we set isAsCheapAsAMove to 1 on the TableGen record, and the default case falls back on that value. What this patch does is override that and make LUIs that are part of address computations _not_ as cheap as a move.

I agree with you. This patch is only a feasible but not perfect scheme for binding the cost evaluation of address computation.
The more difficult is how to establish a cost model, which can analyze multiple related instructions at the same time.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118216/new/

https://reviews.llvm.org/D118216