On Fri, Nov 20, 2020 at 2:48 AM Richard Biener <richard.guent...@gmail.com> wrote: > > 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.
GCC historically has not done a good job at loop unrolling. And tuning of loop unrolling is inherently architecture- and microarchitecture-specific. There is no "better heuristic". There is nothing inherent in the instruction stream to determine an optimal unrolling that is correct for x86 and AArch64 and RISC-V and s390x and Power. Based on what academic literature or experience of other compilers have you determined that this limitation can be addressed with "fix the heuristics"? The patch *IS* trying to fix the heuristics. The heuristics require additional, processor-specific information. And a parameter is the natural mechanism in GCC to provide a numerical value to adjust a heuristic. As Richard wrote, the GCC community chose to collect the "magic numbers" in a centralized table with a consistent interface that can be overridden by individual ports. The ability to override the parameters on the command line was for convenience and ease of development. It's not meant as a value that any end-user normally will adjust. But there is no reason to arbitrarily start a campaign against parameters. GCC supports a large number of targets, and that requires the ability to adjust the optimization and transformation behavior of the compiler to achieve the best performance on a wide variety of processors. We would appreciate it if you would not block a patch that improves the code generation of GCC on Power (and other targets) because of an aesthetic concern about too many parameters in GCC. That ship has sailed. Thanks, David > > > 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
