Basic infrastructure for substitution tracking

Jan Hubicka hubicka@ucw.cz
Thu Sep 24 14:03:00 GMT 2009


> > main ()
> > { 
> >   int nonssa;
> >   int nonssa.0;
> >   int D.2703;
> > 
> > <bb 2>:
> >   # DEBUG ssa => 1
> >   nonssa_5 = 1;
> >   # DEBUG a => &nonssa
> >   D.2703_3 = nonssa_5 + 1;
> >   return D.2703_3;
> > }
> > 
> > looks like ealias should emit new DEBUG statements when turning new symbol into SSA form?
> 
> No, in fact the above is invalid IL as you have still the address taken
> of nonssa in the DEBUG insn.  The update_address_taken pass needs to
> drop DEBUG insns still refering to addresses of variables we are going
> to rewrite into SSA onto the floor.  And yes, the into-ssa should
> generate new DEBUG insns - but I was assuming it already did that, or
> how do we generate the initial set of DEBUG insns?
> 
> Thus, I'd have expected
> 
>  <bb 2>:
>    # DEBUG ssa => 1
>    nonssa_5 = 1;
>    # DEBUG nonssa => nonssa_5
>    # DEBUG a => NULL
>    D.2703_3 = nonssa_5 + 1;
>    return D.2703_3;
> 
> thus, new DEBUG insn for nonssa and the DEBUG insn for a killed
> (the memory is gone now).

Yep, this is what I would expect too.  However I don't think we
neccesarily need to drop a's & expression.  In debug statement I think
&nonssa_5 is sort of valid thing saying "if the SSA name will end up in
memory, this is address of it"...  So user still can inspect value of *a
in debugger while looking at backtrace.

Or if we later do something like b=*a, we can combine info in debug
instructions when removing it and work out that nonssa and b do have
really same values?

Honza
> 
> Richard.



More information about the Gcc-patches mailing list