From: mark_at_yahoo <markrubn@yahoo.com>
To: gcc-help@gcc.gnu.org
Subject: Re: question about knowing when optimization options are used
Date: Wed, 18 Mar 2020 10:44:09 -0700 [thread overview]
Message-ID: <120d7b44-50b6-1868-18e5-27cedd12439a@yahoo.com> (raw)
In-Reply-To: <20200316233406.GE22482@gate.crashing.org>
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.
(Meta-response: I tried sending the following via nabble.com approx. 40
hours ago and it seems not to have gotten through. Apologies if this
eventually shows up as a duplicate.)
Sorry to question this, but my experience has been otherwise. 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".
The above was part of my semi-successful attempt to solve the following
problem:
1) I'm compiling ARM code for an embedded microcontroller with very
limited memory
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?
next prev parent reply other threads:[~2020-03-18 17:44 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 [this message]
2020-03-18 21:24 ` Segher Boessenkool
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=120d7b44-50b6-1868-18e5-27cedd12439a@yahoo.com \
--to=markrubn@yahoo.com \
--cc=gcc-help@gcc.gnu.org \
/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).