From: Daniel Berlin <dberlin@dberlin.org>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: 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 18:03:00 -0000 [thread overview]
Message-ID: <5F3A4178-F827-11D7-B7EE-000A95AF1FAE@dberlin.org> (raw)
In-Reply-To: <20031006175129.GA13871@nevyn.them.org>
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.
>>
>>> A suggestion was to use expr wfl, but that is impractical:
>>> there are too many places where an expressions type is directly
>>> compared with CALL_EXPR (if (TREE_CODE (call) != CALL_EXPR)) -
>>> all of those places would have to be changed to also check for
>>> a EXPR_WITH_FILE_LOCATION that wraps a CALL_EXPR and then
>>> unwrap the call expr in order to subsequentially be able to
>>> process it.
>>
>> What leads you to believe that this is true? Why would not the
>> WFL expr just go through expand_expr, and thence to expand_call?
>
> Well, wouldn't e.g. operand_equal_p need to handle
> EXPR_WITH_FILE_LOCATION? I see lots of other places in the optimizers
> with the same issue. Right now EXPR_WITH_FILE_LOCATION is only used to
> wrap inline calls, as far as I can see. Even there I suspect it hurts
> optimization because of this issue.
God i hated STRIP_WFL.
It was evil.
>
next prev parent reply other threads:[~2003-10-06 18:03 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 [this message]
2003-10-06 19:20 ` Carlo Wood
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=5F3A4178-F827-11D7-B7EE-000A95AF1FAE@dberlin.org \
--to=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).