[llvm] [InitUndef] Enable the InitUndef pass on all targets (PR #108353)
Piyou Chen via llvm-commits
llvm-commits at lists.llvm.org
Thu Sep 12 04:20:39 PDT 2024
BeMg wrote:
> > > The AMDGPU usage is a very literal interpretation of what "early clobber" means, i.e. (some part of) the output might get written before (some parts of) the inputs are read.
> > > For the architectural constraints in ARM and RISCV, is the output forbidden from overlapping with any input, or with one specific input? If the latter, maybe a better way to model it would be with something like `Constraints = "$dst != $src2"` in the tablegen definition of the instruction -- but that would require support in all register allocators, and I don't know how much effort anyone wants to put into better handling for this minor codegen issue.
> >
> >
> > In RISC-V, we are trying to resolve a case involving the `vrgather.vv` instruction by InitUndef, where the destination register cannot overlap with any source register; otherwise, it is considered an illegal instruction.
>
> Thanks. But I also see cases like this:
>
> ```
> lib/Target/RISCV/RISCVInstrInfoV.td
> 1114-// Set earlyclobber for following instructions for second and mask operands.
> 1115:// This has the downside that the earlyclobber constraint is too coarse and
> 1116-// will impose unnecessary restrictions by not allowing the destination to
> 1117-// overlap with the first (wide) operand.
> ```
>
> which sound like they could benefit from a `!=` constraint.
You're right. For some RISC-V instructions, the early-clobber constraint we currently use is too strong. There are many instructions where the destination register could overlap part of the source register (dst != src:sub_1). With the != constraint, we could reduce register pressure, but this would only be beneficial in very compact situations.
I think that even if we implement partial early-clobber constraints, we would still need to use InitUndef for any operand that should be constrained but is marked as undefined.
https://github.com/llvm/llvm-project/pull/108353
More information about the llvm-commits
mailing list