public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
To: Szabolcs Nagy <Szabolcs.Nagy@arm.com>, "dj@redhat.com" <dj@redhat.com>
Cc: 'GNU C Library' <libc-alpha@sourceware.org>
Subject: [PATCH 06/16] malloc: Ensure the generic mtag hooks are not used
Date: Fri, 5 Mar 2021 15:16:40 +0000	[thread overview]
Message-ID: <VE1PR08MB559919F209E1DEF9EE16D3E783969@VE1PR08MB5599.eurprd08.prod.outlook.com> (raw)

Hi,

>> This may make it impossible to compile individual glibc modules with
>> -O0, say, for debugging purposes.  I do this quite often with malloc.c
>> and do not want to lose that ability.
>> 
>> Do we trust the compiler's default optimizations (at -O0) to do code
>> elimination based on constant conditions?
>
> yes, this breaks -O0, i haven't thought of that.

No this works fine. -O0 optimizes if (0) like you'd expect. You do need a bit
of hacking to do it, I tried:

CPPFLAGS-malloc.c += -O0 -D__OPTIMIZE__

> i thought it's better to guard everything with
> one flag in the code than ifdefs (that can be
> runtime flag with tagging enabled or constant 0
> when disabled) since ifdefed code is not checked
> by the compiler.

Agreed, generic C code is better than preprocessed code that is never
checked for all possible configurations.

And to reduce the overhead further without ifuncs we will likely need to
move most of the tagging code into a separate if (tagging_enabled) block
similar to the single-threaded fast path (instead of checking the boolean
many times).

Cheers,
Wilco

             reply	other threads:[~2021-03-05 15:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-05 15:16 Wilco Dijkstra [this message]
2021-03-05 18:15 ` DJ Delorie
  -- strict thread matches above, loose matches on Subject: below --
2021-03-05 19:01 Wilco Dijkstra
2021-03-04 16:30 [PATCH 00/16] memory tagging improvements Szabolcs Nagy
2021-03-04 16:31 ` [PATCH 06/16] malloc: Ensure the generic mtag hooks are not used Szabolcs Nagy
2021-03-05  1:05   ` DJ Delorie
2021-03-05 12:44     ` Szabolcs Nagy
2021-03-05 20:30   ` DJ Delorie

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=VE1PR08MB559919F209E1DEF9EE16D3E783969@VE1PR08MB5599.eurprd08.prod.outlook.com \
    --to=wilco.dijkstra@arm.com \
    --cc=Szabolcs.Nagy@arm.com \
    --cc=dj@redhat.com \
    --cc=libc-alpha@sourceware.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).