fminnm/fmaxnm generation in aarch64

[Andrew Haley]

On 07/05/18 18:08, Indu Bhagat wrote:
> [Trying to get some feedback. I earlier posted on gcc-help a week ago]
> 
> In tree.def -
> 
> /* Minimum and maximum values.  When used with floating point, if both
>  Â Â  operands are zeros, or if either operand is NaN, then it is unspecified
>  Â Â  which of the two operands is returned as the result. */
> DEFTREECODE (MIN_EXPR, "min_expr", tcc_binary, 2)
> DEFTREECODE (MAX_EXPR, "max_expr", tcc_binary, 2)
> 
> I see that the compiler cannot simplify an expression like
> ((a<b)?a:b) into a MIN_EXPR for FP data types without additional flags
> (-ffinite-math-only -fno-signed zeros flags).
> 
> Q1: It is not clear to me what is the fundamental reason of the
>  Â Â Â  "unspecified behaviour" of MIN_EXPR/MAX_EXPR in case of floating point
>  Â Â Â  operands ?
> 
> (For the sake of discussing what I write hereafter, assume that
> fminnm/fmaxnm instructions offer better performance than fcsel/fcmp). So, two
> further questions:
> 
> Q2. If one wants the compiler to generate fminnm/fmaxnm instructions, while
>  Â Â Â  conforming with IEEE standard, the way to do that will be to use math
>  Â Â Â  builtins fmin()/fmax(). Is this correct understanding?

Yes.

> Q3. What will it take for the compiler transform high-level language
>  Â Â Â  floating point construct like ((a<b)?a:b) to a fminnm/fmaxnm insn for
>  Â Â Â  aarch64 targets?

You'd have to use -ffast-math or .ffinite-math-only.  The meaning of the expression
((a<b)?a:b) is not the same as fminnm.  It would be incorrect for GCC to translate
that expression into fminnm.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671