[PATCH] D124183: [InstCombine] Add one use limitation for (X * C2) << C1 --> X * (C2 << C1)

chenglin.bi via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 21 10:25:55 PDT 2022


bcl5980 added a comment.

In D124183#3465096 <https://reviews.llvm.org/D124183#3465096>, @lebedev.ri wrote:

> This is not consistent with our general folding rules.

Can you help to explain the general folding rules? I'm a beginner so it will be grateful you can tell me the detail rules.
At least tell me what case can add one-use and what case can't add. There are many one-use in instcombine so it is important for me.

> What does "may" mean? We'd trade sequential mul-shl for two independent mul.
> Former would be sequential anyway, while two mul may or may not be sequential depending on how bad the microarchitecture is.

I think sequential mul-shr is also very easy to fold to two independent mul in backend but not the other way. If the microarch have enough mul port and don't care too much power they can do this in backend.

> Is there an actual performance bugreport?

No performance report. But the general IR change is also hard to get a large set perf data I think.

> Does this regress e.g. the following case: https://godbolt.org/z/aWsvzW751 ?
> What about the case where the backend isn't even meant to recover, like https://godbolt.org/z/4Tbb3YG3s ?

Thanks for the case you mentioned. Maybe I can add somemore condition to avoid the regression but now I think a rule for one-use is important for me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124183



More information about the llvm-commits mailing list