From: Segher Boessenkool <segher@kernel.crashing.org>
To: mark_at_yahoo <markrubn@yahoo.com>
Cc: gcc-help@gcc.gnu.org
Subject: Re: question about knowing when optimization options are used
Date: Wed, 18 Mar 2020 16:24:04 -0500 [thread overview]
Message-ID: <20200318212404.GM22482@gate.crashing.org> (raw)
In-Reply-To: <120d7b44-50b6-1868-18e5-27cedd12439a@yahoo.com>
On Wed, Mar 18, 2020 at 10:44:09AM -0700, mark_at_yahoo via Gcc-help wrote:
> On 3/16/20 4:34 PM, Segher Boessenkool wrote:
> >You can enable the *flags*, sure, but with -O0 those flags do not do
> >anything. Exactly as the text above says? The "even if" part.
> Sorry to question this, but my experience has been otherwise.
From the manual again:
Most optimizations are completely disabled at '-O0' or if an '-O' level
is not set on the command line, even if individual optimization flags
are specified. Similarly, '-Og' suppresses many optimization passes.
> I haven't
> tried it in a while (probably last did on an older release) but at least
> with gcc-arm, doing:
>
> -O0 \
> -fbranch-count-reg \
> -fcombine-stack-adjustments \
> -fcompare-elim \
> -fcprop-registers \
> <long list of other flags deleted>
>
> *did* do something different than just "-O0".
It might be interesting to see which compiler flag(s) you see any
differences with.
> 2) My code includes header files with literally thousands (no
> exaggeration) of "static const int ..."s
> 3) The code (intentionally) uses only a handful of the consts
> 4) If compiled "-O1", no memory is allocated for the thousands of consts
> (not even the few that are used)
> 5) If compiled "-O0" memory is allocated for each const -- far more
> memory than is available
> 6) "-O0" executables are much easier to debug at the machine instruction
> level (sometimes necessary on microcontrollers)
>
> Can anyone suggest a minimal set of "-f<options>"s to add to -O0 which
> will do what I want, i.e. no code optimizations, but also no memory
> allocated for the consts?
Try -Og instead? It is mostly like -O1, but almost all debugging should
work fine with it (as the option name itself suggests :-) )
Segher
next prev parent reply other threads:[~2020-03-18 21:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-16 23:14 Shrader, David Lee
2020-03-16 23:34 ` Segher Boessenkool
2020-03-16 23:55 ` [EXTERNAL] " Shrader, David Lee
2020-03-17 0:36 ` Segher Boessenkool
2020-03-17 1:39 ` Shrader, David Lee
2020-03-17 1:35 ` Jeffrey Walton
2020-03-17 1:44 ` Shrader, David Lee
2020-03-17 2:58 ` Segher Boessenkool
2020-03-17 12:22 ` Richard Sandiford
2020-03-18 20:15 ` Segher Boessenkool
2020-03-18 17:44 ` mark_at_yahoo
2020-03-18 21:24 ` Segher Boessenkool [this message]
2020-03-19 14:17 ` Jonathan Wakely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200318212404.GM22482@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=gcc-help@gcc.gnu.org \
--cc=markrubn@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).