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

[Daniel Berlin <dberlin at dberlin dot 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.
>