This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]