[PATCH] List lvalue tree codes in non_lvalue

[Roger Sayle <roger at eyesopen dot com>]

The following patch improves the middle-end's non_lvalue function to be
more sensible about generatng NON_LVALUE_EXPR nodes.  The middle-end
annotates folded trees with NON_LVALUE_EXPR to assist front-end parsers
determine whether an "tree" is a can be used as a lvalue of not.  It
does this by wrapping the expression in a NON_LVALUE_EXPR using the
function "non_lvalue".

The problem is that the current implementation generates far more
NON_LVALUE_EXPR nodes than strictly necessary.  These tree codes both
require more memory (slowing the compiler) and potentially interfere
with GCC's tree-level optimizers.  In an analysis of the 2,455,260
calls to non_lvalue during an i686-pc-linux-gnu bootstrap and regression
tests, we currently generate 823191 NON_LVALUE_EXPR nodes.  The current
implementation is atleast clever enough to realize that INTEGER_CST
(which accounts for 1,626,114 or 66% of calls) doesn't need to be wrapped.
However, by listing just this small handfull of exceptions, we
inefficiently wrap 292,894 NOP_EXPRs, 96,578 MULT_EXPRs, 45,738
PLUS_EXPRs, etc... which are all obviously not lvalues, can remain
is_gimple_* and potentially be constant folded further.

The patch below reorganizes the implementation to list the set of tree
codes that could potentially be lvalues.  This list is derived from the
functions: tree-gimple.c:is_gimple_lvalue, c-typeck.c:lvalue_p and
cp/tree.c:lvalue_p_1.  It's better to list all potentially problematic
tree codes, and so I assume all language-specific tree codes need to be
wrapped.  The net result is that we only allocate 299,490 nodes (or 36%)
of the 823,191 NON_LVALUE_EXPRs that were created previously.


[Efforts by front-ends to shrink this list or eliminate the dependence
upon NON_LVALUE_EXPR completely would be encouraged and welcomed :>]


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

Ok for mainline?



2002-05-23  Roger Sayle  <roger@eyesopen.com>

	* fold-const.c (non_lvalue): Explicitly list the tree codes that
	need to be wrapped by NON_LVALUE_EXPR, instead of those that don't.



Index: fold-const.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/fold-const.c,v
retrieving revision 1.381
diff -c -3 -p -r1.381 fold-const.c
*** fold-const.c	22 May 2004 00:27:23 -0000	1.381
--- fold-const.c	23 May 2004 13:31:10 -0000
*************** fold_convert (tree type, tree arg)
*** 1993,2006 ****
  tree
  non_lvalue (tree x)
  {
!   /* These things are certainly not lvalues.  */
!   if (TREE_CODE (x) == NON_LVALUE_EXPR
!       || TREE_CODE (x) == INTEGER_CST
!       || TREE_CODE (x) == REAL_CST
!       || TREE_CODE (x) == STRING_CST
!       || TREE_CODE (x) == ADDR_EXPR)
!     return x;

    return build1 (NON_LVALUE_EXPR, TREE_TYPE (x), x);
  }

--- 1993,2040 ----
  tree
  non_lvalue (tree x)
  {
!   /* We only need to wrap lvalue tree codes.  */
!   switch (TREE_CODE (x))
!   {
!   case VAR_DECL:
!   case PARM_DECL:
!   case RESULT_DECL:
!   case LABEL_DECL:
!   case FUNCTION_DECL:
!   case SSA_NAME:
!
!   case COMPONENT_REF:
!   case INDIRECT_REF:
!   case ARRAY_REF:
!   case BIT_FIELD_REF:
!   case BUFFER_REF:
!   case ARRAY_RANGE_REF:
!   case VTABLE_REF:

+   case REALPART_EXPR:
+   case IMAGPART_EXPR:
+   case PREINCREMENT_EXPR:
+   case PREDECREMENT_EXPR:
+   case SAVE_EXPR:
+   case UNSAVE_EXPR:
+   case TRY_CATCH_EXPR:
+   case WITH_CLEANUP_EXPR:
+   case COMPOUND_EXPR:
+   case MODIFY_EXPR:
+   case TARGET_EXPR:
+   case COND_EXPR:
+   case BIND_EXPR:
+   case MIN_EXPR:
+   case MAX_EXPR:
+   case RTL_EXPR:
+     break;
+
+   default:
+     /* Assume the worst for front-end tree codes.  */
+     if ((int)TREE_CODE (x) >= NUM_TREE_CODES)
+       break;
+     return x;
+   }
    return build1 (NON_LVALUE_EXPR, TREE_TYPE (x), x);
  }


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