On 19 October 2021 15:23:58 CEST, Richard Sandiford via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: >Wilco Dijkstra <wilco.dijks...@arm.com> writes: >> Hi Richard, >> >>> I'm just concerned that here we're using the same explanation but with >>> different numbers. Why are the new numbers more right than the old ones >>> (especially when it comes to code size, where the trade-off hasn't >>> really changed)? >> >> Like all tuning/costing parameters, these values are never fixed but change >> over time due to optimizations, micro architectures and workloads. >> The previous values were out of date so that's why I retuned them by >> benchmarking different values and choosing the best combinations. >> >>> It would be good to have more discussion of why certain numbers are >>> too small or too high, and why 8 is the right pivot point for -Os. >> >> You mean add more discussion in the comment? That comment is already overly >> large and too specific - it would be better to reduce it. The -Os value was >> never >> tuned, and 8 turns out to be faster and smaller than GCC's default. > >The problem is that you're effectively asking for these values to be >taken on faith without providing any analysis and without describing >how you arrived at the new numbers. Did you try other values too? >If so, how did they compare with the numbers that you finally chose? >At least that would give an indication of where the boundaries are.
Maybe you can show csibe benchmark numbers to show the effects: http://szeged.github.io/csibe/ thanks, > >For example, it's easier to believe that 8 is the right value for -Os if >you say that you tried 9 and 7 as well, and they were worse than 8 by X% >and Y%. This would also help anyone who wants to tweak the numbers >again in future. > >BTW, which CPU did you use to do the experiments? Are the tuning >parameters for that CPU already consistent with the new generic values? > >Thanks, >Richard
