> -Original Message-
> From: Wang, Hongyu
> Sent: Saturday, November 19, 2022 2:26 PM
> To: gcc-patches@gcc.gnu.org
> Cc: richard.guent...@gmail.com; ubiz...@gmail.com; Liu, Hongtao
>
> Subject: [PATCH] i386: Only enable small loop unrolling in backend [PR 107602]
>
> Hi,
>
> Followe
On Mon, Nov 21, 2022 at 9:01 AM Liu, Hongtao via Gcc-patches
wrote:
>
>
>
> > -Original Message-
> > From: Wang, Hongyu
> > Sent: Saturday, November 19, 2022 2:26 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: richard.guent...@gmail.com; ubiz...@gmail.com; Liu, Hongtao
> >
> > Subject: [PATC
> It's not necessarily right. unroll_factor will be set as 1 when
> -fno-unroll-loops, which is exactly -fno-unroll-loops means.
Not that exactly, -fno-unroll-loops previously will prevent the pass
from running, and on the current trunk the pass still runs.
Actually I think the implementation on t
On 11/18/22 23:25, Hongyu Wang via Gcc-patches wrote:
Hi,
Followed by the discussion in pr107602, -munroll-only-small-loops
Does not turns on/off -funroll-loops, and current check in
pass_rtl_unroll_loops::gate would cause -funroll-loops do not take
effect. Revert the change about targetm.loop
On Tue, Nov 22, 2022 at 1:41 AM Jeff Law via Gcc-patches
wrote:
>
>
> On 11/18/22 23:25, Hongyu Wang via Gcc-patches wrote:
> > Hi,
> >
> > Followed by the discussion in pr107602, -munroll-only-small-loops
> > Does not turns on/off -funroll-loops, and current check in
> > pass_rtl_unroll_loops::ga
Hi Jeff,
> The reversion of the loop-init.cc changes is fine. The x86 maintainers
> will need to chime in on the rest. Consider installing the loop-init.cc
> reversion immediately as the current state has regressed s390 and
> potentially other targets.
I've posted a patch in
https://gcc.gnu.org