[PATCH] D127801: [InstCombine] convert mask and shift of power-of-2 to cmp+select

Sanjay Patel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 15 10:40:55 PDT 2022


spatel added a comment.

In D127801#3585983 <https://reviews.llvm.org/D127801#3585983>, @bcl5980 wrote:

> Actually even if the instruction number are the same, we still prefer shift+and because cmp port is less than shift for most modern CPU I think.

Yes, some targets may have better throughput, but I don't think there is enough difference to change the decision in IR.

As a counter-example, consider the horrible result for the shift+and pattern with x86 vectors (a target that may not have good support for variable shifts):
https://alive2.llvm.org/ce/z/ciMo-S

So we just have to decide if this canonicalization is worthwhile to improve IR. The backend has to do some work either way to produce optimal code for all targets.

> And I try to create 2 cases: https://alive2.llvm.org/ce/z/exvD7T

Thanks - I understand your point. Although for RISCV64, I don't think we should see the sign extensions in a normal example from source:
https://godbolt.org/z/KWEPPTsx1

> Maybe we can add metadata MD_range for x to keep the information then backend can get enough information to invert the transform.

I haven't looked at metadata in a long time, so I don't know if it is practical. Range metadata is limited on where it can be added (for example, not on function parameters?), and then we have to make sure it is still available for the backend to use.

Since we made similar transforms before this one, this seemed like a good canonicalization to me, but if you think there's too much risk for the backend, we can abandon. If we do that, then we'd likely want to recreate this transform in SDAG, so we can still improve examples like the x86 code I showed in the previous link.


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

https://reviews.llvm.org/D127801



More information about the llvm-commits mailing list