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
