Richard Biener <richard.guent...@gmail.com> writes: > On Mon, May 25, 2020 at 7:44 PM Segher Boessenkool > <seg...@kernel.crashing.org> wrote: >> >> On Mon, May 25, 2020 at 02:39:54PM +0200, Richard Biener wrote: >> > On Fri, May 22, 2020 at 6:54 PM Segher Boessenkool >> > <seg...@kernel.crashing.org> wrote: >> > > > The split above allows the "bug" to be fixed (even on the branch) >> > > > without introducing even more target specialities. >> > > >> > > So does any split. Or I don't see what you mean? >> > >> > Well, a split that does not affect behavior for non-ppc architectures >> > when the flags by users are unchanged. Because that allows >> > the ppc regression to be fixed on the branch. >> > >> > Then, on trunk, we can think of a better overall flag design. Note >> >> Oh, as just a (very) temporary thing, it is fine of course (it should >> say it is then though). >> >> > that cunroll/cunrolli are not controlled by a flag currently, they >> > are gated on optimize >= [2|3] - it's just that either -funroll-loops >> > or -fpeel-loops causes its heuristics to allow code-size growth >> > by its own metrics according to the unroll --params. >> > >> > So it's a bit difficult to retrofit the heuristic behavior onto new >> > flags unless we want to completely move that over to a --param >> > that may be gets adjusted by -funroll-loops. >> >> Yes, cunroll does not have its own option, and that is a problem. But >> that is easy to fix! Either with an option, or just with params (the >> option wouldn't do more than set params anyway?) > > Well, given coming up with different names for essentially the same > transform is going to be challenging how about sth like > > -funroll-loops={early,late,static,dynamic}[insert better names here] > > note there's also -fpeel-loops which may match the transform > done on GIMPLE better? I'm not sure which are the technically > correct terms for unrollings that elide the loop (the backedge). > We're doing such kind of unrolling even if we cannot statically > decide which of a set of possible exits we take (and internally > call that peeling, if we can statically decide we call it complete > unrolling). The RTL side OTOH only performs classical unrolling, > preserving the backedge with various strategies for the > remaining iterations. > > As said, for the regression on the 10 branch with ppc I'd add > [a hidden] flag that controls the RTL unroller, also set by > -funroll-loops and triggered by the ppc specific heuristics.
This way would enable rtl unroller at -O2 instead enable -funroll-loops, and then cunroll will not unroll/peel the loop if there is potential size increasing. This could avoid the negative affect on the loop which mentioned in PR95018 code. While, I still hope to tune cunroll at -O2 for ppc (or general platforms) with keeping possitive and avoid negative affects. Yes, this may align with what Honza plan to do. BR, Jiufu > > Richard. > >> >> Segher