This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

On Mon, Oct 06, 2003 at 02:03:21PM -0400, Daniel Berlin wrote:
> On Oct 6, 2003, at 1:51 PM, Daniel Jacobowitz wrote:
> >On Mon, Oct 06, 2003 at 10:40:54AM -0700, Richard Henderson wrote:
> >>On Sat, Sep 27, 2003 at 02:49:20PM +0200, Carlo Wood wrote:
> >>>But tree-ssa (3.5) even adds a location_t to tree_common!
> >>
> >>Not anymore.
> Instead it adds it to tree_exp and tree_decl.
> Adding it to tree_exp on the mainline would also help solve Carlo's 
> problem.

Then would it be ok for me to add the location_t to tree_exp
already please?  The following patch is an example (although
fully functional):

When using the compiler with and without this patch on very large
C++ compialtion unit, the result of -fmem-report gave:


Size   Allocated        Used    Overhead
Total         30M         24M        291k


Size   Allocated        Used    Overhead
Total         32M         25M        301k

I have no problem with reducing the memory usage, but that will
be a considerably more complex (looking) patch :).
I still don't believe that the WFL is the correct approach,
but I could make the location_t *optional* to tree_exp structs
so that they will only be allocated when it is a CALL_EXP.
In order to not confuse the existing code for non-CALL_EXP tree_exp
objects, this extension would need to be added *after* the
operand[] array.  You you rather see me submit a patch for that
for review?  That will make the extra memory usage go away at
the cost of ... well, at the cost of nothing actually, except
that the patch is more complex to understand :*).  When I proposed
this on IRC, drow said 'it would almost certainly be disapproved'.
But I wouldn't know why.  This approach would be normal 'inheritance'
approach from the object oriented world:

struct tree_exp --> /
		    |  Normal tree_exp
		    |  Extension

It would as if

struct call_expr : public tree_exp {
  location_t locus;

if you get the idea.

Index: gcc/expr.c
RCS file: /cvs/gcc/gcc/gcc/expr.c,v
retrieving revision 1.589
diff -u -d -p -r1.589 expr.c
--- gcc/expr.c	28 Sep 2003 04:56:33 -0000	1.589
+++ gcc/expr.c	6 Oct 2003 18:37:40 -0000
@@ -7909,6 +7909,7 @@ expand_expr (tree exp, rtx target, enum 
 	    return expand_builtin (exp, target, subtarget, tmode, ignore);
+      emit_line_note (EXPR_SOURCE_LOCATION (exp));
       return expand_call (exp, target, ignore);
     case NON_LVALUE_EXPR:
Index: gcc/tree.c
RCS file: /cvs/gcc/gcc/gcc/tree.c,v
retrieving revision 1.330
diff -u -d -p -r1.330 tree.c
--- gcc/tree.c	22 Sep 2003 05:09:12 -0000	1.330
+++ gcc/tree.c	6 Oct 2003 18:37:45 -0000
@@ -2389,6 +2389,9 @@ build (enum tree_code code, tree tt, ...
+  if (code == CALL_EXPR)
+    EXPR_SOURCE_LOCATION (t) = input_location;
   return t;
Index: gcc/tree.h
RCS file: /cvs/gcc/gcc/gcc/tree.h,v
retrieving revision 1.447
diff -u -d -p -r1.447 tree.h
--- gcc/tree.h	28 Sep 2003 19:09:49 -0000	1.447
+++ gcc/tree.h	6 Oct 2003 18:37:49 -0000
@@ -837,9 +837,21 @@ struct tree_vec GTY(())
+/* These two fields describe where in the source code the call was
+   done in the case of a call expression.
+   This is particular useful when the call_expr is buried inside a
+   decl_expr of the function parameters of an inlined function; at
+   that moment the input_location points to the definition of the
+   inlined function, while this call is likely to be done at the
+   same line as the call to the inlined function.  */
 struct tree_exp GTY(())
   struct tree_common common;
+  location_t locus;		/* Used for call expressions only. */
   int complexity;
   tree GTY ((special ("tree_exp"),
 	     desc ("TREE_CODE ((tree) &%0)")))

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]