[llvm] [RISCV][GISEL] Introduce the RISCVPostLegalizerLowering pass (PR #108991)

[Tobias Stadler via llvm-commits]

tobias-stadler wrote:

> If you check out #108859, you can see that `lowerInsertSubvector` and its children have many calls to `MIB.buildXXX` (around 10 static calls to `MIB.buildXXX`). It seems quite yucky to have to manually regbankselect/constrain all all over the lowering/selection code.

> Also, it seems like I cannot test the intermediate lowering since whatever we lower to gets selected and that is what gets tested. This seems against the core value of GISEL easy ability to test specific things.

Last time I looked at AArch64PostLegalizerLowering almost all lowering combines were fairly trivial (mostly single instruction rewrites), so I didn't think these technicalities would be an issue. Your lowering appears to be more complex, so I completely agree.

> I started to constrain them, but apparently only !preISelGenericOpcode instructions are allowed to be constrained. So I am not sure how to constrain them, even if I add in all the extra code to do it.

I don't think I quite understand this issue.  It sounds like you were trying to constrain a RegClass? You should be able to at least use `MRI.setRegBank`. Maybe peek at AMDGPURegBankCombiner to see how they deal with RegBanks.

These technicalities seem solvable though, some ideas off the top of my head:
1. We could set an Observer for the MIB, which assign regbanks on-demand (doesn't exist yet, but seems possible).
2. Test the InstructionSelect debug output, which prints all instruction insertions/deletions (hacky?).

I wanted to experiment with these things before rambling about this without proposing a proper solution. It probably makes the most sense to just run with RISCVPostLegalizerLowering for now unless you feel like experimenting or can live with these limitations.

I am not really attached to the idea of reselecting generic instructions (I hope it will work for AArch64 though). I just think that Combiners are the wrong place for one-shot expansions due to high overhead. In these cases SelectionDAG's split Type and Operation legalization phases kinda make sense. It could make sense to create stripped down single-pass low-overhead versions of either the Legalizer or the Combiner (e.g. without DCE, WorkList, ...) for these cases, but the problem is that just walking over the instructions and searching for certain opcodes is a significant compile-time contributor for O0, so we should aim to reduce the number of necessary O0 passes.



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