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 Wed, 3 Oct 2007, Richard Guenther wrote:

> During RTL optimization a reference or placeholder DECL from the
> sets of associated variables will make var-tracking work as before.
> Only at the time we write out debug information we will need to go
> back to the variable sets and create copies of the variable location
> lists for each of the variable in the associated set.  (fingers crossing,
> this is all pure speculation)

Well, similar propagation and merging of sets need to happen for 
transformations on RTL create copy instructions.

One plan would be to add a new slot to all SET rtxs, which can represent 
the set of user variables associated with the LHS of that very SET (e.g. 
in a PARALLEL with multiple SETs it would be possible to associate 
different sets with the different LHSs).  The semantic would be that after 
_that_ insn the LHS contains all these user variables.  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.  Their runtime semantic is unchanged 
after all.  Some transformations (one offensive one is probably combine) 
simply need to deal with the additional information to preserve it.

> Note that as opposed to the DEBUG_STMT/INSN approach this is _not_ a way 
> we can conveniently cause values to be preserved that would otherwise be 
> deleted.

>From my p.o.v. this aspect of better debug information for some use-cases 
should not be part of general improvements to debug info improvement.  
Forcing some values to be live will inevitably inhibit some 
transformations and therefore optimizations, and hence should only be done 
when really requested by the user.  Otherwise our "-g should not change 
code" dogma (which I agree with) would force us to generally switch off 
some optimizations even without -g, and that I don't want.

So forcing values live should be done by a separate mean, e.g. an 
artificial volatile instruction which uses that value.


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