Patchwork fix for PR49888 var-tracking compile-time regression

login
register
mail settings
Submitter Jakub Jelinek
Date Jan. 16, 2013, 2:15 p.m.
Message ID <20130116141504.GF7269@tucnak.redhat.com>
Download mbox | patch
Permalink /patch/212521/
State New
Headers show

Comments

Jakub Jelinek - Jan. 16, 2013, 2:15 p.m.
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.
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

Patch

--- 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;