fminnm/fmaxnm generation in aarch64

fminnm/fmaxnm generation in aarch64

[Indu Bhagat]

[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?

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?

Thanks!

Re: 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

Re: fminnm/fmaxnm generation in aarch64

[Joseph Myers]

On Mon, 7 May 2018, Indu Bhagat wrote:

> 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?

For IEEE 754-2008 minNum / maxNum operations, which those instructions 
correspond to and fmin and fmax bind to, yes.  For IEEE 754-2018 (in 
progress), there are different minimum / maximum operations, which don't 
match those AArch64 instructions (but some do match RISC-V instructions), 
and there are new proposed corresponding C functions such as fmaximum and 
fminimum_num (I don't know of implementations of those functions).

-- 
Joseph S. Myers
joseph@codesourcery.com