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

[Björn Pettersson via llvm-commits]

bjope wrote:

> There shouldn't be any data dependency within a bundle, hence the actual order of the lowering shouldn't matter

The objective with finalizeBundle is to create the BUNDLE instruction, adding register defs/uses to the BUNDLE instruction in a way so that it represents the outcome of executing the bundled instructions. In order to do that it need to somehow consider the data dependencies between the bundled instructions (e.g. to understand which defs that are live out from the BUNDLE, or which uses that are "internal" in the bundle).

Our target support lots of different things (even having multiple instructions defining the same register, or bundling sequences of instructions that both def and use the same register). The idea with the BUNDLE is to hide such internal dependencies by seeing those instructions as one VLIW bundle. It would however be really bad if we weren't allowed to have data dependencies between the instructions that are to be bundled.

The current (upstream) implementation of finalizeBundle isn't supporting all our use cases, but it do treat the instructions being bundled as a sequence of instructions that _are_ allowed to have data dependencies. It is for example detecting uses of registers defined by earlier instructions in the bundle, adding "internal read" on such uses. It does not consider those uses as being external uses (which I guess it would to do if seeing the set of instruction being bundled as strictly independent of each other).

I got a feeling that these things could be better documented, so that backend developers using bundles would understand how to setup the instruction that are to be bundled in order to get the wanted semantics. Such as making sure that any external use must be prior to a def, since finalizeBundle isn't treating the instructions in the input to finalizeBundle as being independent (even though it might treat the final BUNDLE as being one big "parallel" VLIW instruction).

For our target the bundled instructions will be seen as executing in parallel. The instructions may nevertheless have data dependencies. One example I mentioned earlier is when having a def that is feeding a use in a call instruction in the same bundle, but we also have situations when instructions wouldn't see defs from within the same bundle. To support such things we need to add a couple of hacks to finalizeBundle that are more or less easy to maintain. One problem is that the upstream version isn't very explicit about how these things are supposed to work (which IMHO both makes it a bit hard to review patches, but also to suggest improvements to finalizeBundle).

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