Hi, Segher and Richard

> > Something in your patch was wrong, please fix that (or revert the
> > patch).  You should not have to touch config/rs6000/ at all.
>
> Sure something is wrong, but I think there's the opportunity to
> simplify rs6000/ and s390x/, the only other two implementors of
> the hook used.

If I understand correctly, the wrong part is we should not break the
logic of -funroll-loops and check OPTION_SET_P in
targetm.loop_unroll_adjust to pretend the loop-unrolling is disabled
with -fno-unroll-loops.
I don't have a good idea to resolve this, perhaps add another hook and
check OPTION_SET_P (flag_unroll_loops) && munroll_only_small_loops
there and use that hook in rtl_loop_unroll::gate (), but still it
doesn't work if we want to strictly follow the logic that
-munroll-only-small-loops should not enable loop unrolling.
IMHO the middle-end part with target hook looks quite tricky (and of
course the OPTION_SET_P in the target hook). So Richard if you agree,
I'd like to install the reversion patch posted in
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606774.html
and move all them to the backend first.

-- 
Regards,

Hongyu, Wang

Reply via email to