[llvm] [CodeGen] Fix handling dead redefs in finalizeBundle (PR #157427)

[Björn Pettersson via llvm-commits]

bjope wrote:

Perhaps a bit unrelated discussion (sorry), but some details of finalizeBundle has bothered me for some time.

I haven't really understood the exact semantics that should be expected from finalizeBundle. And we have got a couple of tweaks downstream related to finalizeBundle to satisfy verifiers and out post ra scheduler etc.

One question is if the instructions subject to finalizeBundle should be seen as executing in parallel when it comes to liveness.
An example would be when having input such as
```
  $reg1 = add $reg0, 1
  $reg2 = xor $reg1, 2
```
Should it be assumed that the xor is using the value of $reg1 defined by the add, or the value prior to the bundle (i.e. should the use of $reg1 in the xor be marked as "internal read" here)? When we expand pseudos etc after register allocation we want to create such bundles, and then we want reg1 to be seen as a "use" for the bundle.

A special case of the above is that some instructions actually could be seen as having internal reads. Typical example would be a call instruction, where the callee would read the registers new value if bundling things like: 
```
  $reg0 = add $reg1, 1
  call @callee $reg0,
```
The use of $reg0 in the call should be marked as internalRead, and there should be no use of $reg0 for the BUNDLE.

Downstream we have a TargetInstrInfo hook that describes if a use operand would be "internal" or "external" based on the instruction that is bundled. Upstream it seems like the bundles instructions are semantically seen as a sequence of instructions, rather than a set of instructions executing in parallel.

Another problem is related to the UndefUseSet which upstream tracks if there is at least one undef use of a register. Downstream we intead track NonUndefUsetSet to only mark a use as undef if all uses are undef.
An (possibly odd) example would be when having input such as
```
  $reg0 = add $reg0, 1, implicit $flag
  $reg1 = sub $reg1, 2, implicit undef $flag
```
where upstream version would add "implicit undef $flag" on the BUNDLE, while our downstream implementation would add "implicit undef $flag" as we have at least on non-undef use.

Is this perhaps something that could be seen as a flaw in the current implementation? Would it be interesting to have a finalizeBundle option to denote that the instructions being bundled should be seen as truly parallel and not as a sequence?

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