[PATCH] D88287: [NARY-REASSOCIATE] Support reassociation of min/max

[Evgeniy via Phabricator via llvm-commits]

ebrevnov added a comment.

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

> 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?
>
> Note that given
>
>   %a = undef
>   %b = %a
>
> , `%a` and `%b` have undefined values, and there are no guarantees that they are equal/not equal.
> Since you emitted `icmp`+`select`, you 'read' from `undef`ined `%c` twice, and you are free to get different result each time.

I must be missing something but I don't see how that applies to the above case. I think the problem is not connected with evaluation of %c twice (to different values).
I think the problem is that in the second case "%1 = icmp sgt i32 %smax1, %c" was evaluated to 'false' even though 'smax1' is known to be max_int. But if we replace "undef" with "any" like in the first case it is evaluated to max_int....


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88287