This is the mail archive of the gcc-patches@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: [patches] Re: limited register renaming at -O2


> Well, you just need the right debug hooks.
OK.
(but still how to handle on pre-dwarf2 formats?)
> I added support for location lists to dwarf2 already, and it works
> (I'm not sure i don't have the test for things that are split over
> sections backwards, but that's trivial).
> 
> I'll tell you what.
> If you can make it drop labels i can refer to get the address where a
> variable starts being in a given register, i'll do the rest of the
> work (IE add the debug hooks to say a variable is changing to a new
> register, etc)

My plan is to add post-bb-reorder pass (when life information is still solid,
and CFG don't modify anymore) that will track the cases where variable is
loaded to some register (ie the hardreg with proper ORIGINAL_PSEUDO is set
and track the lifetimes of these variables).

Then I will probably emit notes to the insn stream NOTE_PSEUDO_LOCATION
that will say whether the pseudo is loaded in some variable or whetehr is
on the stack.

The analyzis will be quite tricky, as I need to handle pseudos that allocates
into multiple hardregs.  I am not 100% sure how to do that - maybe adding new
field to REG for this information (but it looks like wasting space) or creating
some more generic way to attach such information to objects, as mem tracking
currently being worked on by Richard Kenner most probably does same thing.

We also needs code that strips lowparts and splits insns to preserve the
NOTE_PSEUDO_LOCATION as we don't do currently.

Then we can use final.c (at that stage we sadly can't build CFG and du such
analysis, so we can just hope that post-final won't mangle the stuff badly)
to call the hook when NOTE_PSEUDO_LOCATION is seen.
> 
> In fact, that's why I didn't add support for it already, because i
> didn't feel like hunting around final.c to figure out how to do this.
> 
> STABS could be extended to do some live range splitting trackign, but
> it's not perfect.
> 
> >
> > Thats why it looked to me like introducing -fmessy-debugging can be usefull
> > thing to do.
> >
> > Honza
> > > 
> >> Bernd
> 
> -- 
> "I went to a 7-11 and asked for a 2x4 and a box of 3x5's.  The
> clerk said, "ten-four."
> "-Steven Wright


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