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