This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: fix for PR49888 var-tracking compile-time regression
On Wed, Jan 16, 2013 at 11:25:46AM -0200, Alexandre Oliva wrote:
> > Can you safely cache the canon addresses already during vt_initialize
> > (when cselib_* is still processing new insns, cselib VALUEs contain
> > REGs and MEMs that are flushed at the end of processing the current bb
> > in vt_initialize)?
>
> No. AFAICT we only call the address canonicalization function after
> collecting all MOps, when the cselib table is fully constructed and
> cleaned up from any local information, retaining only the global
> equivalences.
Weird, I thought I've seen significant time spent in get_addr etc.
already during vt_initialize, e.g. when looking at PR54402, but I might be
wrong.
--- var-tracking.c.xx 2013-01-11 09:03:01.000000000 +0100
+++ var-tracking.c 2013-01-16 15:00:39.012478547 +0100
@@ -2172,11 +2172,14 @@ drop_overlapping_mem_locs (void **slot,
/* Remove from SET all VALUE bindings to MEMs that overlap with LOC. */
+static bool vt_initialize_p;
+
static void
clobber_overlapping_mems (dataflow_set *set, rtx loc)
{
struct overlapping_mems coms;
+gcc_assert (!vt_initialize_p);
coms.set = set;
coms.loc = canon_rtx (loc);
coms.addr = vt_canonicalize_addr (set, XEXP (loc, 0));
@@ -9604,6 +9607,8 @@ vt_initialize (void)
VTI (bb)->permp = NULL;
}
+vt_initialize_p = true;
+
if (MAY_HAVE_DEBUG_INSNS)
{
cselib_init (CSELIB_RECORD_MEMORY | CSELIB_PRESERVE_CONSTANTS);
@@ -9861,6 +9866,7 @@ vt_initialize (void)
}
}
+vt_initialize_p = false;
hard_frame_pointer_adjustment = -1;
VTI (ENTRY_BLOCK_PTR)->flooded = true;
cfa_base_rtx = NULL_RTX;
doesn't ICE on the few testcases I've tried. If it only runs after
vt_initialize, my complain is wrong of course.
> > Also, what effects (if any) does the patch have on the
> > .debug_info/.debug_loc size and coverage?
>
> It shouldn't have any, since it's just caching results that would have
> been recomputed over and over. However, there's a possibility of being
> âluckyâ and recording an equivalence in the cache whose path would later
> be removed from a dynamic set (say, if an incoming VALUE is reset and
> re-bound within a block; I'm not sure this ever actually happens). In
> this case, these retained equivalences might enable alias analysis to
> figure out that two memory refs do not overlap, and so one can be
> retained in a dynamic equivalence list when we process a MOp that
> modifies the other. Or something ;-) It shouldn't really make any
> difference, just speed things up a bit. Paraphrasing Knuth, âI proved
> it, but I didn't test itâ ;-)
Let me do a bootstrap/regtest pair (first one almost finished) to see.
Jakub