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

Daniel Berlin dberlin@dberlin.org
Mon Oct 6 18:03:00 GMT 2003


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.
>



More information about the Gcc mailing list