Re: [PING][Patch] Add support for IEEE-conformant versions of scalar fmin* and fmax*

[Richard Biener <richard.guenther@gmail.com>]

To make progess here I think adding new optabs is fine.  So can you
split out that part and implement builtin expanders
for fmin/max instead?

Btw, FMIN/MAX_EXPR are not commutative AFAIK because of behavior for
fmax (-NaN, NaN)
vs. fmax (NaN, -NaN)?

Richard.

On Mon, Sep 14, 2015 at 12:36 PM, David Sherwood <david.sherwood@arm.com> wrote:
> Hi All,
>
> For what it's worth I have uploaded a new patch that changes the name
> from STRICT_FMIN/MAX to just FMIN/FMAX, although I realise that this
> discussion has not yet been resolved. I have also added scheduling
> attributes to the aarch64 instructions.
>
> Regards,
> David Sherwood.
>
> ChangeLog:
>
> 2015-08-28  David Sherwood  <david.sherwood@arm.com>
>
>     gcc/
>         * builtins.c (integer_valued_real_p): Add FMIN_EXPR and FMAX_EXPR.
>         (fold_builtin_fmin_fmax): For strict math, convert builtins fmin and
>         fmax to FMIN_EXPR and FMIN_EXPR, respectively.
>         * expr.c (expand_expr_real_2): Add FMIN_EXPR and FMAX_EXPR.
>         * fold-const.c (const_binop): Likewise.
>         (fold_binary_loc, tree_binary_nonnegative_warnv_p): Likewise.
>         (tree_binary_nonzero_warnv_p): Likewise.
>         * optabs.h (fminmax_support): Declare.
>         * optabs.def: Add new optabs fmax_optab/fmin_optab.
>         * optabs.c (optab_for_tree_code): Return new optabs for FMIN_EXPR and
>         FMAX_EXPR.
>         (fminmax_support): New function.
>         * real.c (real_arithmetic): Add FMIN_EXPR and FMAX_EXPR.
>         * tree.def: Likewise.
>         * tree.c (associative_tree_code, commutative_tree_code): Likewise.
>         * tree-cfg.c (verify_expr): Likewise.
>         (verify_gimple_assign_binary): Likewise.
>         * tree-inline.c (estimate_operator_cost): Likewise.
>         * tree-pretty-print.c (dump_generic_node, op_code_prio): Likewise.
>         (op_symbol_code): Likewise.
>         * config/aarch64/aarch64.md: New pattern.
>         * config/aarch64/aarch64-simd.md: Likewise.
>         * config/aarch64/iterators.md: New unspecs, iterators.
>         * config/arm/iterators.md: New iterators.
>         * config/arm/unspecs.md: New unspecs.
>         * config/arm/neon.md: New pattern.
>         * config/arm/vfp.md: Likewise.
>         * doc/generic.texi: Add FMAX_EXPR and FMIN_EXPR.
>         * doc/md.texi: Add fmin and fmax patterns.
>     gcc/testsuite
>         * gcc.target/aarch64/fmaxmin.c: New test.
>         * gcc.target/arm/fmaxmin.c: New test.
>
>
>> -----Original Message-----
>> From: Richard Biener [mailto:richard.guenther@gmail.com]
>> Sent: 19 August 2015 14:41
>> To: Richard Biener; David Sherwood; GCC Patches; Richard Sandiford
>> Subject: Re: [PING][Patch] Add support for IEEE-conformant versions of scalar fmin* and fmax*
>>
>> On Wed, Aug 19, 2015 at 3:06 PM, Richard Sandiford
>> <richard.sandiford@arm.com> wrote:
>> > Richard Biener <richard.guenther@gmail.com> writes:
>> >> As an additional point for many math functions we have to support errno
>> >> which means, like, BUILT_IN_SQRT can be rewritten to SQRT_EXPR
>> >> only if -fno-math-errno is in effect.  But then code has to handle
>> >> both variants for things like constant folding and expression combining.
>> >> That's very unfortunate and something we want to avoid (one reason
>> >> the POW_EXPR thing didn't fly when I tried).  STRICT_FMIN/MAX_EXPR
>> >> is an example where this doesn't apply, of course (but I detest the name,
>> >> just use FMIN/FMAX_EXPR?).  Still you'd need to handle both,
>> >> FMIN_EXPR and BUILT_IN_FMIN, in code doing analysis/transform.
>> >
>> > Yeah, but match.pd makes that easy, right? ;-)
>>
>> Sure, but that only addresses stmt combining, not other passes.  And of course
>> it causes {gimple,generic}-match.c to become even bigger ;)
>>
>> Richard.
>