public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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

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