[PATCH] D140647: Handle simple diamond CFG hoisting in DivRemPairs.

Sat Dec 24 10:05:12 PST 2022

lebedev.ri added a comment.

By hoisting div/rem that would be executed anyway,
we allow it to be issued earlier than it would have,
and assuming that the inputs were already ready,
the instructions that use it's result may have to wait
less for said result to be available.

In D140647#4016068 <https://reviews.llvm.org/D140647#4016068>, @barannikov88 wrote:

> The changes in the tests actually show that this transformation is unprofitable.
> Unlike the case above (where Div postdominates both PredBB and Rem), hosting the Div ~~increases~~ may increase critical path length.

Div/rem are usually *extremely* slow, so that code was in a bad spot already.

In D140647#4016069 <https://reviews.llvm.org/D140647#4016069>, @nikic wrote:

> Hm, could you provide some more information on what the motivation for this transform is?

> If we don't have a domination relationship, then we won't be able to reuse a result we have to compute anyway

I don't follow at all. We clearly dominate both of the source blocks?

> so is the intention here a code size improvement for the case where a divrem op exists,
> because we now only need to materialize the instruction once? In that case though,
> does this transform make sense if we are going to use expanded form, as in the PowerPC example?
> We are replacing a div/rem on disjoint code paths with a common div plus mul+sub on one code path, which seems strictly worse?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140647