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
