[llvm-dev] Problem with "[SimplifyCFG] Handle tail-sinking of more than 2 incoming branches"

[Marcello Maggioni via llvm-dev]

Hello,

I’m getting some failures on our internal testing happening after this commit.

I dug a little bit into it and it ended up begin caused by the fact that this optimization is sinking some instructions that shouldn’t be sunk

In particular we have some loads that need to have a constant address to be selected, because they load from a “special address space”.

What the optimization is doing is extracting the “getelementptr” , making an instruction out of it, sinking the load and using a PHI to select between the address.
This breaks our selection of this types of loads.

We need a way to tell this code to not do that.

The solutions I kind of see for this is:

- Add some TTI hook that stops this sinking from happening for instructions that don’t support that like in this case (maybe added in canSinkInstructions())

- Add some TTI hook that is a little bit coarser that stops the optimization to run altogether. In particular this thing is creating “unstructured control-flow” in some cases and this is not always good (and actually generally bad) on GPU targets.

- Put the optimization in another separate pass. It seems to be doing stuff that is a little bit more than just “Simplifying the CFG” actually. It is actually making it more complex by splitting blocks around. I wonder if it would make sense for it to live it in a separate pass that can be enabled or disabled at the compiler pipeline level so that one that wants to opt out can just avoid to add the pass to the pipeline.

Open for suggestions on what the best solution for this is.

Thanks,
Marcello