This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Designs for better debug info in GCC
Hi,
On Mon, 12 Nov 2007, Alexandre Oliva wrote:
> > Why does it make sense to have that, rather than notes on instructions
> > that say what affect the instruction has on user variables?
>
> Few instructions need such notes, so the proposal of growing SET by 33%
> doesn't quite appeal to me.
Though I don't have produced hard numbers yet, that every SET now contains
an additional pointer is less of an issue than one might think. There
only ever exists one RTL body at each point in time, hence the memory use
for RTL is vastly dominated by the memory use of GIMPLE, which exists for
all functions at the same time.
Having this annotation in the SET is just the esthetically most pleasing
place. If you do it with notes on insns you have issues with multi-set
insns, and you have to move them around in case you change the insns.
Putting them in the SET itself keeps them up-to-date nearly automatically
(of course you still have to touch them once in a while).
> That said, growing SET to add to it a list of variables (or components
> thereof) that the variable is assigned to could be made to work, to
> some extent. But when you optimize away such a set, you'd still have
> to keep the note around, so it's not clear to me that adding code all
> over to maintain the notes in place when the SETs go away or are
> juggled around would bring us any advantage.
The nice thing is, that there are only few places which really get rid of
SETs: remove_insn. You have to tweak that to keep the information around,
not much else (though that claim remains to be proven :) ).
Ciao,
Michael.