This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] New regressions as of 2003-11-04
- From: law at redhat dot com
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: gcc-patches at gcc dot gnu dot org, Jan Hubicka <jh at suse dot cz>, Daniel Berlin <dberlin at dberlin dot org>, Diego Novillo <dnovillo at redhat dot com>
- Date: Mon, 10 Nov 2003 15:40:25 -0700
- Subject: Re: [tree-ssa] New regressions as of 2003-11-04
- Reply-to: law at redhat dot com
In message <20031110223036.GA32748@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak wri
tes:
>Hello,
>
>> >Yes; the statement insertion/removal updates this mapping (but just for
>> >sure I will create a patch that adds a test for this to
>> >tree_verify_flow_info).
>> Excellent.
>>
>> I just remembered the other concern I had when I first looked at the
>> patch. Can't a VAR_DECL or PARM_DECL be changed by an ASM_EXPR,
>> CALL_EXPR and possibly other nodes? It seems to me that the test
>> for invalidating the var needs to be a lot more aggressive.
>
>Due to this check
>
>+ if (!ann
>+ || ann->may_aliases
>+ || TREE_ADDRESSABLE (var))
>+ var = NULL_TREE;
>
>it should be safe against CALL_EXPRs (I hope).
Ah yes.
> I am not quite sure about ASM_EXPRs.
I think VA_ARG_EXPR is also problematical since it modifies its argument
and can appear on the RHS of a statement as well. Ugh.
You might just want to punt those cases
if (TREE_CODE (stmt) == ASM_EXPR
|| TREE_CODE (stmt) == VA_ARG_EXPR
|| (TREE_CODE (stmt) == MODIFY_EXPR
&& TREE_CODE (TREE_OPERAND (stmt, 1)) == VA_ARG_EXPR))
invalidate var
Or something close to that.
jeff