public inbox for
 help / color / mirror / Atom feed
From: Jonathan Wakely <>
To: Roman Kellner <>
Cc: Stefan Ring <>, gcc-help <>
Subject: Re: Re: Re: gcc optimization options and lto (detailed info)
Date: Thu, 19 May 2022 10:33:25 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <trinity-dba8f838-b88d-491b-a582-c9be885cb09e-1652951565751@3c-app-gmx-bs42>

On Thu, 19 May 2022 at 10:12, Roman Kellner wrote:
> What I try to understand is how to write "correct" code, if I need to prevent some dedicated code parts or data structures (typically in flash) from being optimized away or moved around, because the program relies on them.
> Since __attribute__((used)), compare , volatile etc. are compiler and language features, all I try to further understand is, which influence such declarations and attributes do have on the different optimization features / strategies.
> It is not that the optimizers do things wrong, but they do not understand the programmers notion.
> I am looking for ways to tell the optimizers what I need ("This data structure/code part needs to stay where it is / how it is. Do not touch").
> And if others have gathered experience with it, providing some hints (do's and dont's).

Thank you, that makes it clearer. I agree you should be fixing the
code to correctly express the intent, and not adding hundreds of
command-line options to try and micro-manage the optimizers, which is
what you seemed to be asking about (which optimizations are active at
which stages, what they're documented to do, how to avoid very long
command lines etc).

It seems what you're really asking about is how to write correct
embedded code, so that it works correctly with different compilers,
even when optimized. Asking about GCC's LTO optimizations is the wrong
goal, I think.

  parent reply	other threads:[~2022-05-19  9:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-17  6:56 muzungu
2022-05-17  8:30 ` Jonathan Wakely
     [not found]   ` <trinity-1d53f520-c371-471b-b6c2-0446d6ba8184-1652865880524@3c-app-gmx-bap04>
2022-05-18 10:23     ` Jonathan Wakely
     [not found]       ` <trinity-dba8f838-b88d-491b-a582-c9be885cb09e-1652951565751@3c-app-gmx-bs42>
2022-05-19  9:33         ` Jonathan Wakely [this message]
2022-05-17  8:54 ` Stefan Ring
2022-05-17 23:05 ` Segher Boessenkool

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* 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).