On 20/01/2021 17:53, mark_at_yahoo via Gcc-help wrote:
> On 1/20/21 7:56 AM, Richard Earnshaw via Gcc-help wrote:
>> On 16/01/2021 20:48, Brent Roman wrote:
>>> Here's an example of a gcc invocation with -O2 followed by disabling all
>>> the -O2 specific optimizations:
>>> ...
>>
>> Sorry, it's not as simple as that. There are places in the compiler
>> where the optimization level (O1, O2, O3) is just tested with
>> something like
>>
>> if (optimize >= level)
>>
>> for some level.
>>
>> R.
>>
>
> Just chiming in with an opinion here. I've had the same problem and came
> to the same conclusion ("-f" options do not fully replace/override "-O")
> although I didn't know the compiler source was that explicit about it
> (thanks for the info).
>
> I realize this is very unlikely to change but find the situation
> unfortunate. My use-case is with the GNU Arm Embedded Toolchain port of
> GCC and my https://github.com/thanks4opensource/regbits development
> system. The latter creates C++ header files with literally thousands of
> constexpr objects of which only a handful are used in a typical program.
> If compiled O1 or above, the linker only allocates storage for the
> objects that are used. At O0 it allocates all of them which makes the
> resulting binary far too large to fit in a typical embedded processor's
> memory space. But O0 is very useful for assembly-level debugging in GDB
> (often required in embedded development) because the generated code is
> much simpler and easier to correlate with the original C++ source.
>
I also work on embedded systems (usually with the ARM gcc toolchain
these days, but at times I use many others).
I /never/ use -O0, precisely because I find it absolutely terrible for
assembly level debugging. You can't see the wood for the trees, as all
local variables are on the stack, and even the simplest of C expressions
ends up with large numbers of assembly instructions. In my experience -
and this is obviously very subjective - using -O1 gives far more
readable assembly code while avoiding the kinds of code re-arrangement
and re-ordering of -O2 that makes assembly-level debugging difficult.
(-Og is an alternative for modern gcc versions, which can give most of
the speed of -O2 but is a little easier for debugging).
Another major benefit of -O1 is that it enables much more code analysis,
which in turn enables much better static checking - I am a big fan of
warning flags and having the compiler tell me of likely problems before
I get as far as testing and debugging.
(Your project here looks very interesting - I'm going to have a good
look at it when I get the chance. I won't be able to use it directly,
as a pure GPL license basically makes it unusable for anything but
learning or hobby use, but as it matches ideas I have had myself I am
interested in how it works.)
> I've only had limited success coming up with a set of -f options to add
> to O0 to eliminate the unused objects but retain the un-optimized binary
> code. The above explains why, but it would be nice if the -O options
> really were just a set of -f ones and users could customize to their
> needs. Without implementing my specific "-O0.5" option. ;)
>
