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]
Other format: [Raw text]

Re: [PATCH] Fix lost locus issues at -O0 -g (PRs debug/29609, debug/36690, debug/37616)


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


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