[PATCH] [ARM] generate VMAXNM/VMINNM for a compare followed by a select (in safe math mode too)

[Artyom Skrobov]

> That's not what I meant. It's to do with the exact semantics in both
> VMAXNM/VMINNM and the DAG it's coming from, to make sure that all edge
> cases are covered.

Yes, I did put together some back-of-the-envelope tables of the possibilities, to check that the semantics are preserved by each of the switch blocks.


> You're using DAG.isKnownNeverNaN(LHS) to mean "is LHS a non-NaN
> constant". For now, that's ok because the function only recognise
> constants, but there's a TODO in there to recognise more cases, which
> could very well get non-constant cases (if they can be traced back).
> Would that affect your premises?

What matters for the transformability is whether the operands are NaN, it doesn't matter whether they're constants.
You're right that my comments there are slightly inaccurate -- they should say "the non-NaN should be RHS" and "the non-NaN should be LHS" instead.
Thanks for catching that!  I'll fix the comments.