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

Artyom Skrobov artyom.skrobov at arm.com
Tue May 5 11:58:28 PDT 2015


Renato, thank you for looking!

> But my ARM ARM (v7A & v8), in VMAX/VMIN says:
>
> Floating-point maximum and minimum
> • max(+0.0, –0.0) = +0.0
> • min(+0.0, –0.0) = –0.0
> • If any input is a NaN, the corresponding result element is the default NaN.

That's correct for VMAX/VMIN; VMAXNM/VMINNM differ from them by returning the non-NaN operand in the case when the other operand is NaN.

> Also, your patch is quite dense, as there's a lot of switch
> fall-throughs and flag switching. Have you tested the edge cases of
> the transformation, or at least built a table with the possibilities
> for the branch combinations?

There are, in fact, only two switch fall-throughs there :-)

I appreciate that the code looks complicated; but it has, in fact, a simple structure.
The first switch block checks if one of the operands is known as non-NaN; and if so, it makes sure the operand is on the correct side of the comparison.
The second switch block deals with signed zeroes, and it aborts the transformation if the operand may be zero with the unacceptable sign.
The last switch block performs the transformation; it's the same code that used to be there before my patch.

My point is that there aren't, in fact, dependencies between the three switch blocks -- each of them operates on different data.
Therefore, it's enough to observe that each of the switch blocks, in isolation, behaves correctly; thence I can conclude that the combination of the three behaves correctly, too.

On top of that, I think that the new test cases cover all of the possible combinations (non-zeroes and zeroes of different signs, on different sides of the comparison, with different comparison operators).







More information about the llvm-commits mailing list