[PATCH] SelectionDAG: mimic InstCombine when comparing to undef

[Owen Anderson]

> On Feb 12, 2015, at 11:36 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
> 
> 
>> On Feb 12, 2015, at 9:25 PM, hfinkel at anl.gov wrote:
>> 
>>> I haven't put a test yet, and it breaks the validation, but before fixing this I seek opinion on NaN handling here. InstCombine does not care and I don't really see why the same IR would be handled differently in the DAG than in InstCombine.
>> 
>> 
>> I don't know either, but that sounds wrong. This depends on the predicate, I think, for fcmp, but NaN != NaN (or anything else), and so we can't arbitrarily fold fcmp pred x, undef to true unless we know that x cannot be NaN (or we're generically allowing unsafe floating-point transformations).
> 
> 
> I’m not sure I can invalidate the reasoning for InstCombine, I need help :)
> 
> // fcmp pred X, undef -> undef
> 
> If we don’t know anything for X, then the result of the comparison can be either true or false. It seems to me completely valid to return “undef”.
> 
> The select will then decide that on “undef” it will always pick the first choice (IIRC).

Consider the specific case of “%0 = fcmp oeq %x, undef; %1 = select %0, %a, %b”
If we optimize then fcmp to undef, then later stages can legitimately optimize the entire sequence to "%1 = %a”

Now, imagine that %x is dynamically NaN.  We have now produce a dynamic contradiction: no matter what value we chose to represent the undef, the final result could never have been %a in this situation.

—Owen