From: Jeff Law <law@redhat.com>
To: Alexandre Oliva <aoliva@redhat.com>
Cc: GCC <gcc@gcc.gnu.org>
Subject: VTA/debugging vs reload-v2
Date: Mon, 05 Apr 2010 16:37:00 -0000 [thread overview]
Message-ID: <4BBA11BC.4060300@redhat.com> (raw)
So as I mentioned in the meeting last week, I've largely been ignoring
VTA (and more generally all debugging) issues with the reload work I'm
doing. It's time to rectify that situation.
For this phase of the work (range splitting) we only need to consider a
few straightforward transformations to the RTL and how they impact the
debugging information.
The goal is to take a pseudo P and break its live range down into P1,
P2, ... Pn where each of the sub-ranges are local to a region (right now
a region is a straight line hunk of code with no join nodes -- not quite
an extended basic block, but close). Outside these regions P lives in
memory. Within each region the new pseudos P1, P2, ... Pn may be
allocated to different hard registers.
We accomplish this by emitting a load from memory into a new pseudo
before the first use of P in a region and a store from the new pseudo
back to memory after the last assignment to P within the region, then we
rename all references from P to P'. It's marginally more complex, but I
think for this discussion the other complexities can be ignored. After
all regions have been processed, P is gone from the insn stream.
Obviously P can be found in memory, P1, P2, ... Pn depending on
precisely where we are in the code when the value is P is requested.
I'm not terribly familiar with how dwarf2 represents variable ranges; I
tend to think of this as P living in memory, except during the
subregions where its in P1, P2, .. Pn. The sub-range pseudos P1, P2,
.. Pn all point back to P via ORIGINAL_REGNO and all have the same
reg_equiv_memory_loc.
So, without having looked closely at dwarf2out.c (it hurts my head every
time I try), is it likely we're going to need to be emitting new
debug_insns to describe how to correctly find P in the different contexts?
Thanks,
Jeff
next reply other threads:[~2010-04-05 16:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-05 16:37 Jeff Law [this message]
2010-04-05 20:33 ` Alexandre Oliva
2010-04-05 23:18 ` Jeff Law
2010-04-06 6:36 ` Jakub Jelinek
2010-04-06 15:23 ` Jeff Law
2010-04-06 15:31 ` Jakub Jelinek
2010-04-07 8:32 ` Alexandre Oliva
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BBA11BC.4060300@redhat.com \
--to=law@redhat.com \
--cc=aoliva@redhat.com \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).