[Committed] New function fold_builtin_abs

[Committed] New function fold_builtin_abs

[Roger Sayle]

This patch allows the middle-end to lower the "abs" family of GCC
built-ins to ABS_EXPR tree nodes.  In addition to adding a new
"fold_builtin_abs", the existing code for BUILT_IN_FABS (et al.)
is factored into "fold_builtin_fabs".  Then, to avoid the
creation of an ABS_EXPR tree node only to be folded away, I export
fold_abs_const from fold-const.c, enabling these new functions to
constant fold calls with constant arguments directly.  Finally,
it removes the call to abort from expand_builtin, such that if
the user and/or front-end attempts something suspicious with these
functions, we fall back to calling the libc routines [matching
the behaviour of GCC's other builtins].

This patch is one of a series of patches that will allow further
simplification of the language front-ends.


The following patch has been tested on i686-pc-linux-gnu with a
full bootstrap, all default languages, and regression tested with
a top-level "make -k check" with no new failures.

Committed to mainline CVS.



2004-06-10  Roger Sayle  <roger@eyesopen.com>

	* fold-const.c (fold_abs_const): Make extern.
	* tree.h (fold_abs_const): Prototype here.
	* builtins.c (fold_builtin_fabs): New function to transform
	fabs, fabsf and fabsl builtins into ABS_EXPR tree nodes.
	(fold_builtin_abs): New function to transform abs, labs, llabs
	and imaxabs builtins into ABS_EXPR tree nodes.
	(expand_builtin): Fall back to a function call for abs, labs,
	llabs and imaxabs builtins that survive constant folding.
	(fold_builtin_1): Call fold_builtin_fabs for FABS, FABSF and
	FABSL, and fold_builtin_abs for ABS, LABS, LLABS and IMAXABS.


Index: fold-const.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/fold-const.c,v
retrieving revision 1.391
diff -c -3 -p -r1.391 fold-const.c
*** fold-const.c	10 Jun 2004 00:02:48 -0000	1.391
--- fold-const.c	10 Jun 2004 03:48:24 -0000
*************** static bool reorder_operands_p (tree, tr
*** 135,141 ****
  static bool tree_swap_operands_p (tree, tree, bool);

  static tree fold_negate_const (tree, tree);
- static tree fold_abs_const (tree, tree);
  static tree fold_not_const (tree, tree);
  static tree fold_relational_const (enum tree_code, tree, tree, tree);
  static tree fold_relational_hi_lo (enum tree_code *, const tree,
--- 135,140 ----
*************** fold_negate_const (tree arg0, tree type)
*** 9846,9852 ****

     TYPE is the type of the result.  */

! static tree
  fold_abs_const (tree arg0, tree type)
  {
    tree t = NULL_TREE;
--- 9845,9851 ----

     TYPE is the type of the result.  */

! tree
  fold_abs_const (tree arg0, tree type)
  {
    tree t = NULL_TREE;
Index: tree.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree.h,v
retrieving revision 1.508
diff -c -3 -p -r1.508 tree.h
*** tree.h	9 Jun 2004 22:58:29 -0000	1.508
--- tree.h	10 Jun 2004 03:48:25 -0000
*************** extern tree fold (tree);
*** 3459,3464 ****
--- 3459,3465 ----
  extern tree fold_initializer (tree);
  extern tree fold_convert (tree, tree);
  extern tree fold_single_bit_test (enum tree_code, tree, tree, tree);
+ extern tree fold_abs_const (tree, tree);

  extern int force_fit_type (tree, int);
  extern int add_double (unsigned HOST_WIDE_INT, HOST_WIDE_INT,
Index: builtins.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/builtins.c,v
retrieving revision 1.333
diff -c -3 -p -r1.333 builtins.c
*** builtins.c	9 Jun 2004 15:32:24 -0000	1.333
--- builtins.c	10 Jun 2004 03:48:26 -0000
*************** static tree fold_builtin_copysign (tree,
*** 166,171 ****
--- 166,173 ----
  static tree fold_builtin_isascii (tree);
  static tree fold_builtin_toascii (tree);
  static tree fold_builtin_isdigit (tree);
+ static tree fold_builtin_fabs (tree, tree);
+ static tree fold_builtin_abs (tree, tree);

  static tree simplify_builtin_memcmp (tree);
  static tree simplify_builtin_strcmp (tree);
*************** expand_builtin (tree exp, rtx target, rt
*** 5628,5640 ****

    switch (fcode)
      {
-     case BUILT_IN_ABS:
-     case BUILT_IN_LABS:
-     case BUILT_IN_LLABS:
-     case BUILT_IN_IMAXABS:
-       /* build_function_call changes these into ABS_EXPR.  */
-       abort ();
-
      case BUILT_IN_FABS:
      case BUILT_IN_FABSF:
      case BUILT_IN_FABSL:
--- 5630,5635 ----
*************** fold_builtin_isdigit (tree arglist)
*** 7587,7592 ****
--- 7582,7619 ----
      }
  }

+ /* Fold a call to fabs, fabsf or fabsl.  */
+
+ static tree
+ fold_builtin_fabs (tree arglist, tree type)
+ {
+   tree arg;
+
+   if (!validate_arglist (arglist, REAL_TYPE, VOID_TYPE))
+     return 0;
+
+   arg = TREE_VALUE (arglist);
+   if (TREE_CODE (arg) == REAL_CST)
+     return fold_abs_const (arg, type);
+   return fold (build1 (ABS_EXPR, type, arg));
+ }
+
+ /* Fold a call to abs, labs, llabs or imaxabs.  */
+
+ static tree
+ fold_builtin_abs (tree arglist, tree type)
+ {
+   tree arg;
+
+   if (!validate_arglist (arglist, INTEGER_TYPE, VOID_TYPE))
+     return 0;
+
+   arg = TREE_VALUE (arglist);
+   if (TREE_CODE (arg) == INTEGER_CST)
+     return fold_abs_const (arg, type);
+   return fold (build1 (ABS_EXPR, type, arg));
+ }
+
  /* Used by constant folding to eliminate some builtin calls early.  EXP is
     the CALL_EXPR of a call to a builtin function.  */

*************** fold_builtin_1 (tree exp)
*** 7628,7636 ****
      case BUILT_IN_FABS:
      case BUILT_IN_FABSF:
      case BUILT_IN_FABSL:
!       if (validate_arglist (arglist, REAL_TYPE, VOID_TYPE))
! 	return fold (build1 (ABS_EXPR, type, TREE_VALUE (arglist)));
!       break;

      case BUILT_IN_CABS:
      case BUILT_IN_CABSF:
--- 7655,7667 ----
      case BUILT_IN_FABS:
      case BUILT_IN_FABSF:
      case BUILT_IN_FABSL:
!       return fold_builtin_fabs (arglist, type);
!
!     case BUILT_IN_ABS:
!     case BUILT_IN_LABS:
!     case BUILT_IN_LLABS:
!     case BUILT_IN_IMAXABS:
!       return fold_builtin_abs (arglist, type);

      case BUILT_IN_CABS:
      case BUILT_IN_CABSF:


Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833

Re: [Committed] New function fold_builtin_abs

[Richard Henderson]

On Thu, Jun 10, 2004 at 07:43:54AM -0600, Roger Sayle wrote:
> -       /* build_function_call changes these into ABS_EXPR.  */
> -       abort ();

The comment directs you do code that is now redundant with your
fold_builtin change.


r~

Re: [Committed] New function fold_builtin_abs

[Roger Sayle]

On Thu, 10 Jun 2004, Richard Henderson wrote:
> On Thu, Jun 10, 2004 at 07:43:54AM -0600, Roger Sayle wrote:
> > -       /* build_function_call changes these into ABS_EXPR.  */
> > -       abort ();
>
> The comment directs you do code that is now redundant with your
> fold_builtin change.

After another three patches the entire function expand_tree_builtin
will be obsolete, and can be removed from C's build_function_call,
and C++'s build_cxx_call and build_function_call.  It will also
avoid the special casing of "fabs" in the Java front-end.

Its far easier for me to make all the necessary changes the the
middle-end (which I can approve for myself), and then propose a
single patch to eliminate "expand_tree_builtin" from c-common.c,
than to incrementally remove functionality from the C and C++
front-ends, requiring permission from the front-end maintainers
for each iteration.

This should clarify the "this is one of a series of patches" remark
in my original posting.

Roger
--

Re: [Committed] New function fold_builtin_abs

[Richard Henderson]

On Thu, Jun 10, 2004 at 11:50:24AM -0600, Roger Sayle wrote:
> This should clarify the "this is one of a series of patches" remark
> in my original posting.

That's fine then.  Just making sure it wasn't forgotten.


r~

Re: [Committed] New function fold_builtin_abs

[Paolo Bonzini]

> This patch allows the middle-end to lower the "abs" family of GCC
> built-ins to ABS_EXPR tree nodes.

I have a patch to add the isnan builtin and lower it to ORDERED_EXPR 
(SAVE_EXPR (x), SAVE_EXPR (x)); shall I wait for this series of patches 
to end before submitting?

Paolo

Re: [Committed] New function fold_builtin_abs

[Roger Sayle]

On Fri, 11 Jun 2004, Paolo Bonzini wrote:
> I have a patch to add the isnan builtin and lower it to ORDERED_EXPR
> (SAVE_EXPR (x), SAVE_EXPR (x)); shall I wait for this series of patches
> to end before submitting?

Some platforms, such as the IA-64, have special instructions to
implement "isnan".  Hence, I'm undecided if the lowering of "isnan"
to *UNORDERED_EXPR* is best done in "fold" or later during RTL
expansion.  Given that tree-ssa doesn't like SAVE_EXPRs, it might
be worthwhile lowering "fold_builtin_isnan" only if a SAVE_EXPR node
isn't required, i.e. for a *_DECLs, constant folding for constants.

Then during RTL expansion, we'll need to treat unordered(x,x) and
isnan(x) identically, checking the isnandfsi optabs first, and if
that fails emitting the unordered comparison.

Possibly, the IA-64 doesn't even need a special "isnandfsi" pattern
if it could support/special case "(UNORDERED (REG:DF x) (REG:DF x)"
using its "fclass.m" opcode.


I don't think my changes should interfere with your proposed "isnan"
patch, so feel free to post something to get the discussion going,
but I do think that "isnan" -> "unordered" is not always a win on
some platforms, and those targets need some thinking about.
I recall RTH had some opinions on canonicalization of isnan?

Roger
--

Re: [Committed] New function fold_builtin_abs

[Richard Henderson]

On Fri, Jun 11, 2004 at 08:56:51AM -0600, Roger Sayle wrote:
> Possibly, the IA-64 doesn't even need a special "isnandfsi" pattern
> if it could support/special case "(UNORDERED (REG:DF x) (REG:DF x)"
> using its "fclass.m" opcode.

To my knowledge, there's no advantage of using fclass over fcmp
for testing for unordered.

Rather fclass comes in handy when you want to check for multiple
special cases simultaneously.  E.g.

	if (isnan(x) || isinf(x))
	  die();
	else
	  doit();

can be done with one fclass instruction.

I suppose it wouldn't be completely out of the question to
come up with some representation for combine that could put
these together, but nothing pops into my head immediately.


r~