On 03/10/2015 11:27 AM, Richard Biener wrote: > On Tue, Mar 10, 2015 at 10:19 AM, Andreas Krebbel > <kreb...@linux.vnet.ibm.com> wrote: >> On 03/10/2015 10:12 AM, Steven Bosscher wrote: >>> On Tue, Mar 10, 2015 at 8:57 AM, Andreas Krebbel wrote: >>>> >>>> * gcc/ifcvt.c (if_convert): >>>> >>> >>> ...yes...? >> >> Damn. mklog is still not able to do the complete job for me ;) >> >>> Tiny nail, huge hammer. This triggers a full re-scan of all insns and >>> a re-calculation of all dataflow problems. >>> >>> The transformations in ifcvt are all simple enough that it should be >>> possible to just clean up that redundant insn at the site where the >>> code transformation is performed. >> >> Agreed. I was hoping to get this low risk version into 5.0. > > Low risk? High risk of heavy compile-time regression I'd say > (make a testcase that triggers a lot of iteration).
Just to have some numbers I did run a -j1 GCC bootstrap twice with and without the patch on x86_64. Best results for both are: clean: 21459s patched: 21314s There rather appears to be a trend towards reduced compile time perhaps due to the reduced number of INSNs to be processed in the RTL passes between the two ifcvt runs (loop optimization, combine, fwprop, dse,...)?! I also tried to measure the testsuite runs but the results show a big variance. So what I have right now does not qualify as a benchmark. Bye, -Andreas- > > Is this fixing a regression in some way? > > Richard. > >> Bye, >> >> -Andreas- >> >> >
