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.sherw...@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.sherw...@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.guent...@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.sandif...@arm.com> wrote: >> > Richard Biener <richard.guent...@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. >