On Wed, 18 Sep 2019 at 01:46, Richard Biener <richard.guent...@gmail.com> wrote: > > On Tue, Sep 17, 2019 at 7:18 PM Wilco Dijkstra <wilco.dijks...@arm.com> wrote: > > > > Hi Richard, > > > > > The issue with the bugzilla is that it lacked appropriate testcase(s) and > > > thus > > > it is now a mess. There are clear testcases (maybe not in the benchmarks > > > you > > > > Agreed - it's not clear whether any of the proposed changes would actually > > help the original issue. My patch absolutely does. > > > > > care about) that benefit from code hoisting as enabler, mainly when > > > control > > > flow can be then converted to data flow. Also note that "size > > > optimizations" > > > are important for all cases where followup transforms have size limits on > > > the IL > > > in place. > > > > The gain from -fcode-hoisting is about 0.2% overall on Thumb-2. Ie. it's > > definitely > > useful, but there are much larger gains to be had from other tweaks [1]. So > > we can > > live without it until a better solution is found. > > A "solution" for better eembc benchmark results? > > The issues are all latent even w/o code-hoisting since you can do the > same transform at the source level. Which is usually why I argue > trying to fix this in code-hoisting is not a complete fix. Nor is turning > off random GIMPLE passes for specific benchmark regressions. > > Anyway, it's arm maintainers call if you want to have such hacks in > place or not. > > As a release manager I say that GCC isn't a benchmark compiler. > > As the one "responsible" for the code-hoisting introduction I say that > as long as I don't have access to the actual benchmark I can't assess > wrongdoing of the pass nor suggest an appropriate place for optimization. Hi Richard, The actual benchmark function for PR80155 is almost identical to FMS() function defined in pr77445-2.c, and the test-case reproduces the same issue as in the benchmark.
Thanks, Prathamesh > > Richard. > > > > > [1] https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01739.html > > > > Wilco
