[PATCH] D111806: [LICM] Check the number of divergent paths from loop header to target block

Fri Oct 15 10:32:12 PDT 2021

reames added a comment.

In D111806#3066336 <https://reviews.llvm.org/D111806#3066336>, @SjoerdMeijer wrote:

> @lebedev.ri , @reames : I am not saying this the right patch, but just wanted to leave a thought about LICM being a canonicalizing transform. The situation where we are in at the moment, is that LICM is deemed a canonicalisation transform, but we don't have a solid solution in the backend to undo this. LoopSink is an IR pass, works with profile info, and is unsuitable if register pressure needs to be taken into account. MachineSink would be the natural place for this, but currently lacks the ability to sink back into loops. Some work was started to address this, D94308 <https://reviews.llvm.org/D94308>, but that needs finishing and isn't the end of the story. It would need more heuristics, and then get enabled, so that is quite a way off from where we want to be.
>
> Long story short, I think it is a bit easy to say this is a canonicalization transformation. I am not ready to challenge this, not sure I ever will, but just saying that we are in a limbo and not really in a good situation with this.

In D111806#3066336 <https://reviews.llvm.org/D111806#3066336>, @SjoerdMeijer wrote:

> ..., but we don't have a solid solution in the backend to undo this.

I would have a lot more sympathy for this argument if the examples being presented weren't near trivial sinking.  The only example checked in with D87551 <https://reviews.llvm.org/D87551> is a multiply used to implement a square operation.  Such an instruction can (on x86, before regalloc) be trivially moved as a) it's non-faulting, b) it uses only a second register input so moving it as it worst neutral and c) the input and output are the same register class.  The only mildly complicated bit is modeling the implicit eflags dead def, but even there, the location we sink to immediately kills it as well.

If we can't handle cases that simple in our sinking transforms, we should not workaround them elsewhere.  That's embarrassing, and we should simply fix it.

If we were being presented with hard cases to undo with a cost based transform, I might be willing to entertain the notion that LICM should be non-canonical.  As it stands, I don't see such examples.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111806/new/

https://reviews.llvm.org/D111806