On Fri, Nov 20, 2020 at 12:58 AM Segher Boessenkool <seg...@kernel.crashing.org> wrote: > > On Thu, Nov 19, 2020 at 03:30:37PM -0700, Jeff Law wrote: > > > No, the vast majority of people will *not* (consciously) use them, > > > because the target defaults will set things to useful values. > > > > > > The compiler could use saner "generic" defaults perhaps, but those will > > > still not be satisfactory for anyone (except when they aren't generic in > > > fact but instead tuned for one arch ;-) ) -- unrolling is just too > > > important for performance. > > Then fix the heuristics, don't add new PARAMS :-) > > I just said that cannot work? > > > It didn't even occur to me until now that you may be pushing to have the > > ppc backend have different values for the PARAMS. I would strongly > > discourage that. It's been a huge headache in the s390 backend already. > > It also makes a huge performance difference. That the generic parts > of GCC are only tuned for x86 (or not well tuned for anything?) is a > huge roadblock for us. > > I am not saying we should have six hundred different tunings. But we > need a few (and we already *have* a few, not params but generic flags, > just like many other targets fwiw). > > We *do* have a few custom param settings already, just like aarch64, > ia64, and sh, actually. > > > >> In my mind fixing things so they work with no magic arguments is best. > > >> PARAMS are the worst solution. A -f flag with no arguments is somewhere > > >> in between. Others may clearly have different opinions here. > > > There is no big difference between params and flags here, IMO -- it has > > > to be a -f with a value as well, for good results. > > Which is a signal that we have a deeper problem. -f with a value is no > > different than a param. > > Yes exactly. > > > > Since we have (almost) all such tunings in --param already, I'd say this > > > one belongs there as well? > > I'm not convinced at this point. > > Why not? > > We have way many params, yes.
--params were introduced to avoid "magic numbers" in code and at the same time not overwhelm users with many -f options. That they are runtime-controllable was probably done because we could and because it's nice for GCC developers. > But the first step to counteract that > would be to deprecate and get rid of many existing ones, not to block > having new ones which can be useful (while many of the existing ones are > not). Not sure about this - sure, if heuristic can be simplified to use N < M (previous) "magic" numbers that's better. But if "deprecating" just involves pasting the current --param default literally into the heuristcs then no, please not. For this particular patch the question is if the heuristic is sound, not the particular magic number. And I have no opinion about this (being this is the RTL unroller). Richard. > > Or, we could accept that it is not really a problem at all. You seem to > have a strong opinion that it *is*, but I don't understand that; maybe > you can explain a bit more? > > Thanks, > > > Segher
