From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id 0AF2A385843E for ; Thu, 19 May 2022 09:33:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0AF2A385843E Received: by mail-wr1-x42f.google.com with SMTP id u3so6310279wrg.3 for ; Thu, 19 May 2022 02:33:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=GSyY+DjSW76Tg/K2UohsPdNOLm2WGzp8i37/JmjvBQM=; b=tgPOxQJ+fa1GCCuRTSW9fKBhdZGR/k8Xlkm5aaCgMwIRDHsbfpO3w8BJE6cIoA8ns0 m1QeICtW7hbi1ThoqdF91fvno4LJ8DLJl14kBgxl8lVoZ3iOcVhc7QUCbYYNIMkihtTH EUa533QZtNfHwzMNZhuT938OR9AD8Fa/C4m1JM2rGyN2qOrRkgPo0rZcuQdHz+06euX6 LQQD8AhcWTeRZpdhY4VfevSyd8NfHeJcItlLLOXRmTOLJ5bXWxPD3IW4c/cUC1RP29UT XsxA4xMvVhhxaGm55G7Mld4dEpApgHiG8b/x/p6kqrXjVnQ7ulHe8gQS+sC4tzw1mRWa 0GAA== X-Gm-Message-State: AOAM532bxbb3vDdxr4KGfrHhX/aQ6V/qNCS85ACPS5WyICAqmRlmXTrP pkjfq0I3k4KjQfN+xqt2LkD2Cc9SlkLGoJGM9c4= X-Google-Smtp-Source: ABdhPJwTNRHc5T1ZQ2fKGr3NZjLhMJbp9KY5ghYbOpcI/BgJH9wzyYNcwnm51Ch8KTF2A/7Z10jNWgE8VJ1DmYubSCY= X-Received: by 2002:a5d:64e6:0:b0:20c:4f23:96fc with SMTP id g6-20020a5d64e6000000b0020c4f2396fcmr3275283wri.154.1652952816669; Thu, 19 May 2022 02:33:36 -0700 (PDT) MIME-Version: 1.0 References: <062812e4-e912-4eaf-876c-91006a6c47a6@gmx.net> In-Reply-To: From: Jonathan Wakely Date: Thu, 19 May 2022 10:33:25 +0100 Message-ID: Subject: Re: Re: Re: gcc optimization options and lto (detailed info) To: Roman Kellner Cc: Stefan Ring , gcc-help Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2022 09:33:39 -0000 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 pre= vent 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 https://www.keil.com/support/man/doc= s/armclang_ref/armclang_ref_chr1359124978363.htm , volatile etc. are compil= er and language features, all I try to further understand is, which influen= ce such declarations and attributes do have on the different optimization f= eatures / 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 stru= cture/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.