> On Fri, 4 Oct 2019, Jan Hubicka wrote: > > > > I don't really understand the purpose of having 2 params where one is used > > > for -O2 and the other for -O3 (I didn't check -Os), instead of a single > > > param whose default value depends on -On (what we had before?). Is it so > > > that we can more easily mix some functions compiled at -O3 with other > > > functions compiled at -O2 and thus using a different param? > > > > The point is that the auto-inlining we want to do at -O3 is too much for > > what we want to do at -O2. For C++ codebases it is really important to > > auto-inline and thus I have enabled it by default for -O2+ while previously > > we auto-inlined only with -O3 unless the resulting code was expected to > > shrink. Making all -O2 code suddenly 30-50% bigger is not a good idea. > > > > So for inliner (and some other optimizations) we really want to have > > conservative and agressive tuning options. > > I completely agree with all that, I was just wondering about the technical > way you achieve it. You end up writing essentially: > > val = (opt >= 3) ? param : param_for_O2; > > and I was wondering why not just > > val = param; > > but making sure that the default value of param is different for O2 > (conservative) and O3 (aggressive). Basically moving the conditional one > step earlier, so the param has a single name for users. But that's not very > important, feel free to ignore.
The problem is that we do not have any ifrastructure to specify different params for different optimization levels. I posted patches for that earlier this year but Richard did not like it and suggested to go this way for time being and see how many parameters needs to be forked. > > > By the way, did you mean to close the parenthesis so late > > if (opt_for_fn (n->decl, optimize >= 3)) > > or earlier > > if (opt_for_fn (n->decl, optimize) >= 3) > > ? It doesn't matter, just looks surprising. This is definitly typo. I will fix that. Honza > > -- > Marc Glisse
