Re: Keep static VTA locs in cselib tables only

[Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>]

Hi,

this seem to have caused a bootstrap failure on s390x: PR51735

/home/andreas/git/gcc-head/gcc/tree-ssa-pre.c: In function ‘bool
insert_aux(basic_block)’:
/home/andreas/git/gcc-head/gcc/tree-ssa-pre.c:3791:1: internal compiler error:
Segmentation fault

Bye,

-Andreas-

On 11/23/2011 11:10 AM, Alexandre Oliva wrote:
> This patch reduces VTA memory consumption and even speeds it up
> somewhat, by avoiding recording permanent equivalences in dataflow sets
> (and propagating them all the way down the control flow graph), keeping
> them in cselib tables only.  This saves some micro-operations, some
> duplicate attempts to expand the same complex operations, and most of
> all time and memory for locations in dataflow sets.
> 
> I've also moved reverse operations and entry values, that are also
> permanent equivalences, to cselib tables, introducing a mechanism to add
> equivalences to cselib tables that doesn't depend on expressions hashing
> equal: instead, locs for values in an equivalence set are grouped in the
> loc list for the earliest (canonical) value in the set, in the cselib
> tables, with a single entry in the loc list for all other set members
> pointing to the canonical value.
> 
> The downside is that we don't sort loc lists in cselib as we do in
> var-trackin, so we don't give expressions the same preferences we did
> before, which means there's some potential for debug info degradation,
> particularly for preferring entry value expressions over concrete
> expressions guaranteed to have an available value.  I'm going to see
> whether sorting gets us better/faster results next, but just sorting
> them won't get us all the way: while before we'd sort all equivalences
> for the var-tracking-canonical equivalence, we may now fail to merge
> location lists because the static equivalences aren't taken into account
> when dynamic equivalence sets in var-tracking dataflow sets.  I haven't
> thought about whether this makes much of a difference, or how to do that
> efficiently if desirable, but I figured I wouldn't wait any longer
> before submitting this patch for 4.7.
> 
> This was regstrapped on i686-pc-linux-gnu and x86_64-linux-gnu.  I've
> also run some debug info, memory and compile-time measurements:
> 
> - compiling stage3-gcc/ (--enable-languages=all,ada) became some 1-2%
> faster on average (0.5% to 5% speedups were observed over 3
> measurements)
> 
> - comparable speedups with a not-very-random sample of preprocessed
> sources that used to be VTA bad-performers, with var-tracking memory use
> down by 10% to 50%.
> 
> - compiling stage2 target libs and stage3 host patched sources (with
> both unpatched and patched stage2 compiler) produced cc1plus with 10%
> fewer entry value expressions (a welcome surprise!), 1% fewer call site
> value expressions, an increase of 0.1% in the total number of variables
> with location lists and less than 0.5% decrease in variables with full
> coverage.
> 
> Here's the patch.  Ok to install?
> 
> 
> 
> 
> 
>