[PATCH] D69686: [LVI][CVP] Use block value when simplifying icmps

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 28 13:28:11 PDT 2020


nikic added a comment.

In D69686#2298687 <https://reviews.llvm.org/D69686#2298687>, @dmgreen wrote:

> Hello.
>
> We've ran into an issues with a case like this:
> https://godbolt.org/z/KnvGvo
>
> This now manages to prove that the "max" in a saturating the max(min(X, 32767), -32768) is always false. For some cpu's that's fantastic, and give a decent speed increase. But others have a ssat instruction that can do that saturation quickly, that match from a min(max(..)).
> Same goes for MVE instructions where there are a lot of saturating instructions we were previously picking (even if we were not doing it optimally before).
>
> Any ideas of a good way of re-proving that the lower bounds don't need to be checked, but in the backend during ISel?
>
> (In this case the _only_ value that can saturate is a -32768*-32768 multiply, but the code remains and the performance change can be quite substantial. )

I don't have a good suggestion here. This doesn't seem to be provable from known bits or known sign bits reasoning (...right?) and I don't think there's any range based reasoning available at the SDAG level right now. Maybe that would be the motivation to introduce it...

I'm pretty surprised this managed to survive this long. I guess IPSCCP did not fold this yet because it doesn't handle SPF.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69686



More information about the llvm-commits mailing list