[PATCH] D88287: [NARY-REASSOCIATE] Support reassociation of min/max
Nuno Lopes via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Feb 26 02:38:34 PST 2021
nlopes added a comment.
In D88287#2589378 <https://reviews.llvm.org/D88287#2589378>, @ebrevnov wrote:
> I think this is an issue of verification itself. In the first case max(0, undef)=>any and max(any, max_int)=>max_int. In the second case max(max_int, undef)=>x03002006. I believe the behavior of the verifier is inconsistent in these two cases and max(max_int, undef) should be evaluated to max_int as well. We can do the following trivial transformations to prove that: max(max_int, undef) is trivially equal to max(max_int, max(undef, undef)) and max(undef, undef) should be evaluated to 'any' since max(0, undef) is evaluated to 'any' in the first case. Thus we get max(max_int, any) which is evaluated to 'max_int' in the first case. So max(max_int, undef) should be evaluated to 'max_int' but not 'x03002006'.
>
> Makes sense?
Just to add to what Roman wrote, thinking of the code as max(,) is misleading. The code is doing `icmp sgt INT_MAX, undef` which can evaluate to true or false. But we cannot assume that undef from now on is equal to INT_MAX just because the comparison evaluated to true.
The are 2 possible fixes:
1. only do the optimization if `%c` is known non-undef (use ValueTracking's utility), e.g., https://alive2.llvm.org/ce/z/sLeOE0
2. freeze `%c`, e.g., https://alive2.llvm.org/ce/z/ZX557G
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D88287/new/
https://reviews.llvm.org/D88287
More information about the llvm-commits
mailing list