On Thu, Apr 5, 2012 at 2:49 PM, Robert Dewar <de...@adacore.com> wrote: > >> It's on my large TODO list, somewhere at the bottom, to propose >> to make -O1 stop after early optimizations and drop right to >> expansion from there. That would turn optimization expectations >> upside-down of course, but early optimizations should be mostly >> reducing code size (and thus increase compile speed) with >> no fancy optimization that inhibit debugging (SRA, IPA-SRA, >> switch conversion and function splitting are an exception, >> but all but SRA are not enabled at -O1). So we'd move to >> compile-time and debuggability for -O1 (I'd expect compile time >> that should be better or at least not a lot slower than -O0). > > > I am all in favor of such work, but I would approach it in two > steps. First make it a separate -O level, then depending on > how successful this is in practice, propose making -O1 mean > this new level. > > If you do both steps at once, you get opposition on the basis > of change-is-bad, rather than to the substance of the new > level of optimization.
Ok, that were my thoughts as well. It was suggested to add -Og in the past, which, at some point could become the default for a plain 'gcc' invocation. It happens that people care for -O0 and that -O2 is tuned quite well - -O1 did not see any adjustments in the last 10 years I think (well, not based on any benchmarking at least). Not sure if inflation of -O variants will be well-received though ;) Re-using -O looked appealing to me ... Richard. >> >> >> Richard. > >
