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?) Segher
