Re: fix for PR49888 var-tracking compile-time regression

[Jakub Jelinek <jakub@redhat.com>]

On Wed, Jan 16, 2013 at 11:25:46AM -0200, Alexandre Oliva wrote:
> > 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” ;-)

Ok, seems it is almost no change, but if I do between
--enable-languages=all,obj-c++,ada,lto,go --enable-checking=yes,rtl
x86_64-linux and i686-linux (the latter without ,ada) trees (once without
your var-tracking.c patch, once with) readelf -WS comparison of all the
gcc/*.o gcc/*/*.o files from stage3, I get differences beyond
var-tracking.o (which is of course expected):

for i686-linux tree-ssa-pre.o is different, and
for x86_64-linux go/export.o is different.
All other objects have the same readelf -WS output (not comparing .debug_*
section data, as that could be slightly different as I haven't done the
build with exactly the same object directory (different dirname, but same
length thereof)).  If I strip those two object files, then they are
identical between the two trees.  There are some differences in .debug_loc
in both cases.

	Jakub