On Wed, Nov 23, 2022 at 2:53 AM Hongyu Wang <wwwhhhyyy...@gmail.com> wrote: > > 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.
Fine by me. Richard. > -- > Regards, > > Hongyu, Wang
