From: Jakub Jelinek <jakub@redhat.com>
To: Ian Lance Taylor <iant@google.com>
Cc: gcc-patches@gcc.gnu.org, Jan Hubicka <jh@suse.cz>,
Jan Kratochvil <jkratoch@redhat.com>
Subject: Re: [PATCH] Fix lost locus issues at -O0 -g (PRs debug/29609, debug/36690, debug/37616)
Date: Wed, 08 Oct 2008 10:26:00 -0000 [thread overview]
Message-ID: <20081008101959.GR13196@tyan-ft48-01.lab.bos.redhat.com> (raw)
In-Reply-To: <m3d4ic1d20.fsf@google.com>
Hi!
While backporting the patch to 4.3-RH, I've discovered one case where I
haven't handled the goto_locus(location_t)+goto_block -> goto_locus(int locator)
translation, which on the trunk didn't trigger on any of the testcases, but
could, and on 4.3 branch it did.
If a GIMPLE_COND branches with both edges to bb's other than next, and the
true edge has goto_locus set, that one isn't translated, as the caller's
code to translate goto_locus isn't reached when expand_gimple_cond returns
non-NULL.
Fixed thusly, ok for trunk?
Slightly off topic, I wonder whether in the out of cfglayout !optimize code
I shouldn't compare locator's block and location_t separately instead of
just comparing the locators, as it is possible to have different RTL
locators for the same < location_t, block > pair.
There isn't a function to compare two locators, nor there is a function
to get a block from locator, only from insn, so I guess I'd have to add
that.
But this leads to questions about the internal representation of the
RTL locators. Currently we have 2 pairs of vectors, one used separately for
location_t and one for block, always one vector in the pair has int values
and the other has location_t (also 32-bit) or tree (32-bit or 64-bit
depending on host) and the lookup looks quite expensive (binary search).
For 32-bit hosts, wouldn't just using 2 vectors, one with location_t and one
with tree, both indexed by the RTL locator int, be always more compact (and
obviously faster)? For 64-bit hosts perhaps this could be slightly bigger
than current representation if there are far more location_t changes than
block changes (likely), but at least couldn't we avoid the binary
search for the location_t side and just use directly indexed vector?
2008-10-08 Jakub Jelinek <jakub@redhat.com>
* cfgexpand.c (expand_gimple_cond): Convert also goto_block and
goto_locus of true_edge into RTL locator.
--- gcc/cfgexpand.c.jj 2008-10-08 11:50:40.000000000 +0200
+++ gcc/cfgexpand.c 2008-10-08 11:52:27.000000000 +0200
@@ -1725,6 +1725,14 @@ expand_gimple_cond (basic_block bb, gimp
maybe_dump_rtl_for_gimple_stmt (stmt, last2);
+ if (true_edge->goto_locus)
+ {
+ set_curr_insn_source_location (true_edge->goto_locus);
+ set_curr_insn_block (true_edge->goto_block);
+ true_edge->goto_locus = curr_insn_locator ();
+ }
+ true_edge->goto_block = NULL;
+
ggc_free (pred);
return new_bb;
}
Jakub
next prev parent reply other threads:[~2008-10-08 10:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-01 14:54 Jakub Jelinek
2008-10-07 17:09 ` Ian Lance Taylor
2008-10-07 17:35 ` Jakub Jelinek
2008-10-07 18:41 ` Ian Lance Taylor
2008-10-08 10:26 ` Jakub Jelinek [this message]
2008-10-08 10:48 ` Eric Botcazou
2008-10-08 11:00 ` Richard Guenther
2008-10-08 11:01 ` Jakub Jelinek
2008-10-08 11:19 ` Richard Guenther
2008-10-08 14:52 ` Ian Lance Taylor
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=20081008101959.GR13196@tyan-ft48-01.lab.bos.redhat.com \
--to=jakub@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=iant@google.com \
--cc=jh@suse.cz \
--cc=jkratoch@redhat.com \
/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).