Re: [PATCH] New predicate covering NOP_EXPR and CONVERT_EXPR

[Roger Sayle <roger at eyesopen dot com>]

Hi Richard,

On Thu, 1 Dec 2005, Richard Guenther wrote:
> For unifying handling of NOP_EXPR and CONVERT_EXPR and possibly getting
> rid of either of these, this adds a new predicate covering now both
> and in future the remaining one.

I believe there's a better way to reach that goal, with less churn
to the source code.  Back in 4.1's stage1 timeframe I investigated
the following line of investigation:


Index: tree.def
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree.def,v
retrieving revision 1.115
diff -c -3 -p -r1.115 tree.def
*** tree.def    9 Apr 2005 01:37:28 -0000       1.115
--- tree.def    15 May 2005 20:38:44 -0000
*************** DEFTREECODE (RANGE_EXPR, "range_expr", t
*** 724,735 ****

  /* Represents a conversion of type of a value.
     All conversions, including implicit ones, must be
!    represented by CONVERT_EXPR or NOP_EXPR nodes.  */
  DEFTREECODE (CONVERT_EXPR, "convert_expr", tcc_unary, 1)

- /* Represents a conversion expected to require no code to be generated.
*/
- DEFTREECODE (NOP_EXPR, "nop_expr", tcc_unary, 1)
-
  /* Value is same as argument, but guaranteed not an lvalue.  */
  DEFTREECODE (NON_LVALUE_EXPR, "non_lvalue_expr", tcc_unary, 1)

--- 724,732 ----

  /* Represents a conversion of type of a value.
     All conversions, including implicit ones, must be
!    represented by CONVERT_EXPR nodes.  */
  DEFTREECODE (CONVERT_EXPR, "convert_expr", tcc_unary, 1)

  /* Value is same as argument, but guaranteed not an lvalue.  */
  DEFTREECODE (NON_LVALUE_EXPR, "non_lvalue_expr", tcc_unary, 1)

Index: tree.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree.h,v
retrieving revision 1.727
diff -c -3 -p -r1.727 tree.h
*** tree.h      11 May 2005 16:25:30 -0000      1.727
--- tree.h      15 May 2005 20:38:45 -0000
*************** enum tree_code {
*** 40,45 ****
--- 40,49 ----

  #undef DEFTREECODE
+ /* ??? Temporarily define NOP_EXPR to be synonymous with CONVERT_EXPR to
+    ease the transition to consistently using CONVERT_EXPR everywhere.
*/
+ #define NOP_EXPR CONVERT_EXPR
+
  /* Number of language-independent tree codes.  */
  #define NUM_TREE_CODES ((int) LAST_AND_UNUSED_TREE_CODE)



Then with the simple (but mechanical) fall-out of removing the
duplicate case values in switch statements, it's possible to unify
NOP_EXPR and CONVERT_EXPR, and bootstrap C, C++, Obj-C and the
fortran front-ends and their run-time libraries.

The only thing preventing this unification, at that time, was the
Java front-end which inadvertantly distinguishes between CONVERT_EXPR
and via parse.y:patch_cast.  It turns out that in the Java front-end
all explicit casts written by the programmer are represented by
CONVERT_EXPR, though front-end idioms and folding may introduce
NOP_EXPRs.  It turns out that patch_cast is only prepared to handle
user casts, and tweaking parse.y:14429 to treat NOP_EXPR and
CONVERT_EXPR equivalently causes problems, as the type conversions
encoded with NOP_EXPRs aren't valid in the Java language.  For
example, it prohibits casts to void, and casts fron integer types
to booleans and between pointer types and arrays.


If we could get the Java maintainers help with sorting out the
patch_cast issue, I'd prefer that we make a instantaneous surgical
change, rather than the churn of a transition via NOP_CONVERSION_P.
Perhaps the Java front-end needs a front-end tree code to distinguish
user casts from the middle-end's NOP_EXPRs?  Once "there can be only
one", there'd be no need for NOP_CONVERSION_P, and the middle and
front-ends would consistently use comparisons against CONVERT_EXPR.
Ultimately, we poison NOP_EXPR.


What do you think?  Clearly I've given this some thought :)
I think the fold -> foldN -> fold_buildN transition worked well
for gcc 4.1.


If you're interested I've still got the rest of the above patch,
but I doubt that it'll apply cleanly given that its six months
old.  However, you should be able to reproduce my investigation
with relatively little effort.


Thoughts?

Roger
--