[PATCH][ARM] Enable code hoisting with -Os (PR80155)

[Richard Biener]

On Wed, Sep 18, 2019 at 6:47 PM Prathamesh Kulkarni
<prathamesh.kulkarni@linaro.org> wrote:
>
> On Wed, 18 Sep 2019 at 01:46, Richard Biener <richard.guenther@gmail.com> wrote:
> >
> > On Tue, Sep 17, 2019 at 7:18 PM Wilco Dijkstra <Wilco.Dijkstra@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.

So on that code-hoisting identifies the redudnant
transitions[S1]++;
stmts, but only the load and increment because it doesn't hoist stores.
I think that's ultimately useful and would be even profitable if we manage
to hoist the stores as well.  If you have access to the actual benchmark
you can do this transform in the source and measure the effect.

Richard.

> Thanks,
> Prathamesh
> >
> > Richard.
> >
> > >
> > > [1] https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01739.html
> > >
> > > Wilco