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. Richard. > > [1] https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01739.html > > Wilco
