[PATCH] D59227: [GlobalISel][Utils] Teach getConstantVRegVal how to look through trunc and z|sext

[Matt Arsenault via Phabricator via llvm-commits]

arsenm added a comment.

In D59227#1427643 <https://reviews.llvm.org/D59227#1427643>, @qcolombet wrote:

> > Why wouldn't G_CONSTANT be legalized? This doesn't make any sense to me
>
> Because they are just place holder.
>  When doing selection, only the ones that won't be folded into immediate should be materialized and at this point, we just have to materialize load immediate into valid registers.
>
> The only reason the constant show up as instructions right now is because we wanted to handle machine operand uniformly via vreg. Otherwise, they would just be immediate operands. If you imagine that setting, I guess it is more obvious why we don't legalize them.
>
> Does it make sense?


This isn't how I think of G_CONSTANT. I think of it as a mov setting a legal result register that is a legitimate instruction in its own right and not just a placeholder. The immediate folding rules for AMDGPU are somewhat complex, so an arbitrary constant is always going to be selected as a materializing move. We wouldn't want G_* instructions to always fold constant operands since that would create more work. A directly selected instruction would be wrong by default. We have a later target pass to fold these based on the selected instruction rules (which can also account for the number of uses of materialized constants etc.). For operands that truly need to be constants that shouldn't be legalized, I don't think G_CONSTANT should be used. This is part of the motivation behind D58232 <https://reviews.llvm.org/D58232>. In SelectionDAG there is the TargetConstant vs. Constant distinction, but I think that makes less sense here, so weird constants should just never be materialized.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D59227