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