public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ard Biesheuvel" <ardb@kernel.org>
To: Mike Beaton <mjsbeaton@gmail.com>
Cc: Laszlo Ersek <lersek@redhat.com>,
	devel@edk2.groups.io,  Ard Biesheuvel <ardb@google.com>
Subject: Re: [edk2-devel] [PATCH] BaseTools/tools_def: Disable unneeded-internal-declaration warning in CLANGPDB
Date: Tue, 12 Dec 2023 08:49:24 +0100	[thread overview]
Message-ID: <CAMj1kXH73_q97terq95jZ976seaS-f_-dCwHdV+shPopvgTHvQ@mail.gmail.com> (raw)
In-Reply-To: <CAHzAAWQOTQdh0wOXLxMw0QiYO-DXwTJ_AHVX72ZFkFAerpmptA@mail.gmail.com>

On Tue, 12 Dec 2023 at 08:17, Mike Beaton <mjsbeaton@gmail.com> wrote:
>
> > > A completely different approach, which allows clang to spot that the
> > > usage has been 'optimised away' and so to not complain (and therefore
> > > allows us to re-enable the warning in CLANGDWARF as well), is the
> > > following:
> > >
> > > --- a/MdePkg/Include/Library/DebugLib.h
> > > +++ b/MdePkg/Include/Library/DebugLib.h
> > > @@ -426,7 +426,10 @@ UnitTestDebugAssert (
> > >        }                            \
> > >      } while (FALSE)
> > >  #else
> > > -#define DEBUG(Expression)
> > > +#define DEBUG(Expression)        \
> > > +    if (FALSE) {                   \
> > > +      _DEBUG (Expression);         \
> > > +    }
> > >  #endif
> > >
> > >  /**
> > >
> >
> > But will this not litter the object files with a bunch of format strings
> > etc?
>
> Yes. Which would be optimized away at link time. (Or rather, I believe
> so, would need further tests to confirm exactly what is optimized away
> when.)
>

Link time optimization does not usually optimize away assets at this
granularity. Even if --gc-sections is set, the only thing it can
optimize away is an entire input section.

However, the compiler should be smart enough not to emit any
references to format strings etc in the first place, as it knows the
condition can never become true (but NOOPT builds should retain them).

> > It feels like, for CLANGPDB (and maybe CLANGDWARF), the RELEASE target
> > should not define MDEPKG_NDEBUG, but make sure (instead) that
> > DebugPrintEnabled() evals to FALSE. If PcdDebugPropertyMask is
> > fixed-at-build, then DebugPrintEnabled() should be possible to evaluate
> > at compile time; is that right? (At least for clang?)
>
> Yes, that is my understanding of how compile-time Pcds work too - but
> wouldn't the net result be the same as what I suggested?

It depends on the kind of access. For PCDs that are fixed-at-build
only, the FixedPcdGet###() accessors will evaluate to constant
preprocessor expressions, allowing the compiler to do optimizations.
The ordinary PcdGet###() routines will not produce compile time
constant expressions in the same way, so there, all the logic is
retained (again, modulo LTO)


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112359): https://edk2.groups.io/g/devel/message/112359
Mute This Topic: https://groups.io/mt/103087794/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



  reply	other threads:[~2023-12-12  7:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-10 10:18 [edk2-devel] [PATCH] BaseTools/tools_def: Disable unneeded-internal-declaration warning in CLANGPDB Mike Beaton
2023-12-10 10:22 ` Mike Beaton
2023-12-10 10:25   ` Mike Beaton
2023-12-11 15:00 ` Laszlo Ersek
2023-12-11 15:18   ` Mike Beaton
2023-12-11 16:22     ` Laszlo Ersek
2023-12-11 17:26       ` Mike Beaton
2023-12-12  0:41         ` Laszlo Ersek
2023-12-12  7:17           ` Mike Beaton
2023-12-12  7:49             ` Ard Biesheuvel [this message]
2023-12-12  8:48               ` Mike Beaton
2023-12-12 10:12                 ` Mike Beaton
2023-12-12 10:30                   ` Mike Beaton

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-list 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=CAMj1kXH73_q97terq95jZ976seaS-f_-dCwHdV+shPopvgTHvQ@mail.gmail.com \
    --to=devel@edk2.groups.io \
    /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