This is the mail archive of the gcc@gcc.gnu.org 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]

Re: Debugging data on Alpha


  In message <Pine.LNX.4.30.0012291222320.24133-100000@host140.cambridge.redhat
.com>you write:
 > I had an idea yesterday.  I was working on a few patches that make us
  > keep the original pseudo register number in the second field of a REG,
  > so that we can look it up after reload has completed.  The idea is that
  > maybe this could be used as a starting point for better debugging
  > support with register renaming and LRS optimizations.  We'd stop bothering
  > with the BLOCK notes and re-create the necessary information during the
  > final pass by establishing a mapping between hard regs and user variables
  > at all points in the function.
  > I'm not really familiar with the debugging output code, so I can't tell
  > whether this is feasible.  Comments?
Hmmm.  Interesting.  The trick for debugging register renaming and LRS is
that you have to be able to map a pseudo to a set of hard registers over
specific lifetimes.

You'd have to generate new REG objects during register renaming so that you
can have multiple instances of the original user variable in different hard
regs.  Then you could walk over all the REG objects you created to build
the map.  Ugh.  There's got to be something better.

For LRS you typically have multiple pseudos for what was originally a single
pseudo, so it's a similar problem.  We keep track of the mapping by having
a special note which holds the map (and the begin/end notes mark the region
in which the map is valid).

I thought the original idea behind using that field to hold the original
pseudo # was related to your next reload revamp somehow (I've forgotten how
though).

jeff


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