This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] New SSA variable mapping infrastructure

On Oct  4, 2007, Michael Matz <> wrote:

> One plan would be to add a new slot to all SET rtxs,

Yuck, too much memory overhead even if no debug info is requested.
Notes with an index or pointer to indicate which set they refer to
would probably be better.

> The semantic would be that after 
> _that_ insn the LHS contains all these user variables.

This is imprecise, not only in terms of point of assignment, but also
in terms of which loc lists should be an lvalue and which should be
rvalues.  When the same LHS has the value for multiple variables, it
probably *is* only one of them, and it holds a copy of the others.
You don't want a debugger user that tries to tell the debugger to
modify variable a, that had been copied from b, and end up modifying
b.  We should be able to denote this somehow.  And no, I don't have a
complete answer for this yet, but I do have some thoughts.

> var-tracking would then nearly automagically create the right
> location notes.

> An additional benefit is that not many places in RTL land would have to 
> be changed to deal with those SETs.

You heavily underestimate the use of emit_move_insn().  Each of these
is a point that would require at least some investigation to tell
whether it needs adjusting:

% grep -nH -e emit_move_insn *.[ch] | wc -l

and then, there's reload, that might need to be taught to annotate the
copies it makes.

And, for this, I do have a solution, and it might actually help
alleviate the need for adjusting reload, but not necessarily other
uses of emit_move_insn().  It's the DF-globalized cselib analysis I
mentioned elsewhere
(, bullet 4),
that uses the new debug annotations as basis to propagate location
information about user variables backward and forward, based on
locations that contain equivalent values.  It still doesn't fully
answer the question of how to determine where the lvalue location of a
variable is at any point, if any, though.

Alexandre Oliva
FSF Latin America Board Member
Red Hat Compiler Engineer   aoliva@{,}
Free Software Evangelist  oliva@{,}

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]