This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [vta, vta4.4] merged with trunk and 4.4 @149247, updated VTA patchset
On Tue, Jul 7, 2009 at 8:06 PM, Alexandre Oliva<aoliva@redhat.com> wrote:
> On Jul ?7, 2009, Alexandre Oliva <aoliva@redhat.com> wrote:
>
>>> + ? ? ? ? ? ? if (gimple_code (def_stmt) == GIMPLE_ASSIGN
>>> + ? ? ? ? ? ? ? ? && TREE_TYPE (gimple_assign_rhs1 (def_stmt))
>>> + ? ? ? ? ? ? ? ? && gimple_assign_rhs2 (def_stmt)
>>> + ? ? ? ? ? ? ? ? && TREE_TYPE (gimple_assign_rhs2 (def_stmt)))
>>> + ? ? ? ? ? ? ? value = gimple_assign_rhs_to_tree (def_stmt);
>
>>> err - what is this testing? ?Maybe you want
>>> is_gimple_assign (def_stmt)
>>> && (gimple_assign_rhs_class (def_stmt) == GIMPLE_BINARY_RHS
>>> || gimple_assign_rhs_class (def_stmt) == GIMPLE_UNARY_RHS))
>
>> Yeah, it looks like I totally mangled it while merging tuples. ?It
>> doesn't even begin to make sense AFAICT. ?Thanks for catching this.
>
> Turns out it did make sense, in a twisted way. ?I failed to add the
> critical comment.
>
> The scenario goes like this (multiple statements in between omitted):
>
> ?index_X = something;
> ?pointer_Y = somearray + index_X;
> ?# debug pointer => pointer_Y
>
> Now, pointer_Y is dead, and dropping it makes index_X dead as well, so
> tree-ssa-dce decides to remove both.
>
> We release_ssa (index_X) first. ?This adds index_X to the free list,
> disconnects it from its DEF STMT and all its uses, and zeroes out pretty
> much everything (including TREE_TYPE) in the index_X SSA_NAME, but the
> reference to it in the pointer_Y DEF remains.
>
> Then we release_ssa (pointer_Y). ?At this point, the adjust function
> called by release_ssa will attempt to replace pointer_Y in the debug
> stmt with somearray + index_X, but re-creating this tree fails the
> assertion check for POINTER_PLUS_EXPR, because index_X is typeless.
>
>
> Ideally, we'd like to substitute pointer_Y and then index_X, rather than
> end up losing track of debug information. ?This would work if ssa-dce
> walked stmts backwards in eliminate_unnecessary_stmt(), visiting
> dominated blocks before their dominators.
>
> I'm not sure this is the only situation in which this problem arises,
> but would such an improvement be acceptable?
Well, why not generate stuff at release_ssa_name time, for both
index_X and pointer_Y.
What you do in the hunk I complained about is completely unsafe
if you ever hit dead SSA names.
Richard.
> --
> Alexandre Oliva, freedom fighter ? ?http://FSFLA.org/~lxoliva/
> You must be the change you wish to see in the world. -- Gandhi
> Be Free! -- http://FSFLA.org/ ? FSF Latin America board member
> Free Software Evangelist ? ? ?Red Hat Brazil Compiler Engineer
>