Re: Debugging data on Alpha

[Bernd Schmidt <bernds at redhat dot com>]

On Fri, 29 Dec 2000, Jeffrey A Law wrote:

>   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.

Yes.  We're doing this already - we have to generate new REGs anyway since
they usually are shared across insns and simply changing the number would
have Unwanted Effects.

> 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).

It could be solved by setting ORIGINAL_PSEUDO of the new range registers to
the same value as the ones they are replacing.  If we had code to construct
debugging info from ORIGINAL_PSEUDO, the LRS code would hardly need to do
anything to support it.

> 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).

Yes, I think it was your suggestion.  My reload patch is going through some
contortions to figure out lifetimes of pseudos after alter_reg has been run;
I can probably clean this up a bit now.


Bernd