This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][ARM] Enable code hoisting with -Os (PR80155)
On Mon, Sep 16, 2019 at 2:59 PM Wilco Dijkstra <Wilco.Dijkstra@arm.com> wrote:
>
> Hi Prathamesh,
>
> > My only concern with the patch is that the issue isn't specific to
> > code-hoisting.
> > For this particular case (reproducible with pr77445-2.c), disabling
> > jump threading
> > doesn't cause the register spill with hoisting enabled.
> > Likewise disabling forwprop3 and forwprop4 prevents the spill.
> > The last time I tried, setting setting
> > max-jump-thread-duplication-stmts to 20 and
> > fsm-scale-path-stmts to 3, not only removed the spill but also
> > resulted in 9 more hoistings,
> > but regressed some other test on jump threading.
> > So I was wondering whether we should look into fine-tuning relevant params,
> > instead of disabling code hoisting entirely (we will end up regressing
> > some test cases either way) ?
>
> The point is that -fcode-hoisting is the optimization that made some benchmarks
> run significantly slower compared to older GCC versions. It's been more than 2.5
> years without progress, so let's just fix it now in the obvious way.
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
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.
Richard.
> Yes, there are likely better solutions. And if someone writes an acceptable patch
> then we can easily enable hoisting again. Surely it is far better to have a fixed
> compiler *now* rather than wait a few more years for a solution that has the
> same effect but which might not be trivially backportable?
>
> Cheers,
> Wilco
>