This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] New SSA variable mapping infrastructure
- From: Michael Matz <matz at suse dot de>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 4 Oct 2007 08:27:45 +0200 (CEST)
- Subject: Re: [RFC] New SSA variable mapping infrastructure
- References: <84fc9c000710031126h26263c21yc30e9defa7bc6468@mail.gmail.com>
Hi,
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.
Ciao,
Michael.