[PATCH] D77202: [Target][ARM] Fold or(A, B) more aggressively for I1 Vectors

Dave Green via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Apr 26 14:52:28 PDT 2020


dmgreen added a comment.

The test here look like an improvement, but I'm not sure this would be true for all cases.

The old code said something like "if we know that both operands can be inverted, invert the OR."
The new code looks more like "if we know the operands can be inverted; invert them. Else if we know either can't be inverted, don't invert. Else if we know _nothing_ about the operands; invert them, and hope for the best".

If we are going to go this route (if we think it's generally profitable, It's hard to tell with how many other little problems we have in predicate code generation), I think it might make more sense to improve the checks for when we invert or not. We could just always try invert it but I doubt that works very well. What do you think about testing if at least one side of the 'and' can be inverted, I think that might be enough to justify the transform. That should at least either remove a NOT or convert the AND to an OR. And a so long as one of the sides is a VCMP, we will be able to fold the and into the compare.

It doesn't look like we have a fold for "(not vcmp) -> vcmp". It might be better to have PerformORCombine_i1 just produce not(and(not, not), (providing it looks profitable) and have other combines fold the not's into vcmps/anything else.


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

https://reviews.llvm.org/D77202





More information about the llvm-commits mailing list