public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Carlo Wood <carlo@alinoe.com>
To: Daniel Berlin <dberlin@dberlin.org>
Cc: Daniel Jacobowitz <drow@mvista.com>,
	gcc@gcc.gnu.org, Richard Henderson <rth@redhat.com>
Subject: Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.
Date: Mon, 06 Oct 2003 19:20:00 -0000	[thread overview]
Message-ID: <20031006192046.GB9460@alinoe.com> (raw)
In-Reply-To: <5F3A4178-F827-11D7-B7EE-000A95AF1FAE@dberlin.org>

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:

without:

Size   Allocated        Used    Overhead
Total         30M         24M        291k

with:

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, ...
 	TREE_SIDE_EFFECTS (t) = 1;
     }
 
+  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(())
 #define TARGET_EXPR_INITIAL(NODE) TREE_OPERAND_CHECK_CODE (NODE, TARGET_EXPR, 1)
 #define TARGET_EXPR_CLEANUP(NODE) TREE_OPERAND_CHECK_CODE (NODE, TARGET_EXPR, 2)
 
+/* 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.  */
+#define EXPR_SOURCE_LOCATION(NODE) (EXPR_CHECK (NODE)->exp.locus)
+#define EXPR_SOURCE_FILE(NODE) (EXPR_SOURCE_LOCATION (NODE).file)
+#define EXPR_SOURCE_LINE(NODE) (EXPR_SOURCE_LOCATION (NODE).line)
+
 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)")))

  reply	other threads:[~2003-10-06 19:20 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-22  2:31 RFC: debug line info & inlining; patch proposal and request for comments Carlo Wood
2003-09-23  5:33 ` Jim Wilson
2003-09-27 16:38 ` RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only Carlo Wood
2003-10-06 12:58   ` Hans-Peter Nilsson
2003-10-06 17:41   ` Richard Henderson
2003-10-06 17:51     ` Daniel Jacobowitz
2003-10-06 18:03       ` Daniel Berlin
2003-10-06 19:20         ` Carlo Wood [this message]
2003-10-06 19:08     ` Carlo Wood
2003-10-06 20:11       ` Richard Henderson
2003-10-06 20:14         ` Daniel Jacobowitz
2003-10-06 20:20           ` Richard Henderson
2003-10-06 20:24             ` Daniel Jacobowitz
2003-10-06 21:54               ` Richard Henderson
2003-10-06 21:53             ` Carlo Wood
2003-10-06 21:55               ` Richard Henderson
2003-10-06 22:30                 ` Carlo Wood
2003-10-06 23:17                   ` Richard Henderson
2003-10-06 23:49                     ` Carlo Wood
2003-10-07  0:07                       ` Richard Henderson
2003-10-07  0:43                         ` Carlo Wood
2003-10-07  0:46                           ` Richard Henderson
2003-10-07  2:40                             ` Carlo Wood
2003-10-07 18:32                             ` Carlo Wood
2003-10-07 19:08                               ` Carlo Wood
2003-10-07 19:46                               ` Richard Henderson
2003-10-07 21:12                                 ` Carlo Wood
2003-10-07 23:43                                   ` Carlo Wood
2003-10-07 19:41                 ` Carlo Wood
2003-10-12  4:32             ` law
2003-10-12 12:02               ` Daniel Berlin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031006192046.GB9460@alinoe.com \
    --to=carlo@alinoe.com \
    --cc=dberlin@dberlin.org \
    --cc=drow@mvista.com \
    --cc=gcc@gcc.gnu.org \
    --cc=rth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).