On Fri, Mar 31, 2017 at 11:37 AM, Richard Biener <rguent...@suse.de> wrote: > On Fri, 31 Mar 2017, Markus Trippelsdorf wrote: > >> On 2017.03.31 at 11:16 +0200, Richard Biener wrote: >> > On Fri, 31 Mar 2017, Richard Biener wrote: >> > >> > > On Fri, 31 Mar 2017, Rainer Orth wrote: >> > > >> > > > Hi Christophe, >> > > > >> > > > > With this patch, the following testcase now fails on arm* targets: >> > > > > gcc.dg/tree-ssa/pr71347.c scan-tree-dump-not optimized ".* = MEM.*;" >> > > > >> > > > same on Solaris/SPARC. >> > > >> > > I've reverted r241968 with (patch reverted). It doesn't include >> > > sparc, so please amend as you see fit. >> > >> > Ah, r241441. I'll fixup myself then. >> >> It also fails on some X86 configurations: >> https://gcc.gnu.org/ml/gcc-regression/2017-03/msg00237.html >> https://gcc.gnu.org/ml/gcc-regression/2017-03/msg00238.html > > I see. The test is somewhat strange (well, it's an IVOPTS test). To > simulate the effect of the PRE changes we could simply enable > -fpredictive-commoning on it. > > Let's ask Bin what the testcase was supposed to test... (the testcase > comment suggests that pcom is applied but it certainly wasn't before > the xfails were removed).
It's supposed to test that both loads inside loop can be optimized, X[i-1] by predcom or pre; X[1] by loop invariant. When the test is added, neither pre nor predcom (not at O2) can do this, but we have another chance that pre + ivopts + dom together can eliminate X[i-1]. But this really depends on each pass does the right thing. That's also why it is added with ivopts change. Back in time, it was ivopts did "wrong". Apparently, having a test on different passes is fragile. I will send a patch adding option "-fpredictive-commoning" because predcom seems the right pass to do that. Also given we are considering enabling predcom at O2 for GCC 8. Thanks, bin > > Richard.
