[llvm] [RISCV] Don't forward AVL in VSETVLIInfo if it would clobber other definitions (PR #97264)

[Luke Lau via llvm-commits]

lukel97 wrote:

> If I'm following the logic of this patch, don't we need to adjust the equally-zero reasoning in transferBefore as well? That extends the live range of an AVL too doesn't it?
>
> If so, I think we're also missing an assert in insertVSETVLI that the AVL we're trying to extend has a single def.

I've added an assert in 5ab755c972327b4d2c118db9b694d199a981579f. The AVL can have multiple defs but in all these cases register is already live at the point (and so extending it is a noop I believe).

I think you're right about the equally-zero reasoning though, but I can't seem to get it to trigger the above assertion. Here's my thinking of the different cases that can occur when inserting a vsetvli with a register AVL:

The AVL doesn't need extended:
  - The AVL is from the AVL operand of the pseudo. Already live at that point

The AVL register might need extended:
  -  The AVL was forwarded: we check that it has one value, and this should only happen when the vsetvli dominates the pseudo so it should be available on all paths.
  - A PseudoVMV_S_X only demands AVL zeroness, so transferBefore keeps the previous info's AVL which is an `ADDI $x0, >=32`. But this never seems to trigger the assertion because in this case we always emit a vl-preserving vsetvli x0,x0, and don't end up using the register.

I think the latter case is mostly working by coincidence. #89089 defers the x0,x0 form and would expose the issue. I'll have a think and see if I can get anywhere with your COPY idea.

https://github.com/llvm/llvm-project/pull/97264