public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/88101] Implement P0528R3, C++20 cmpxchg and padding bits
Date: Fri, 20 Nov 2020 11:31:48 +0000	[thread overview]
Message-ID: <bug-88101-4-6vSA14RQ3M@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-88101-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:1bea0d0aa5936cb36b6f86f721ca03c1a1bb601d

commit r11-5196-g1bea0d0aa5936cb36b6f86f721ca03c1a1bb601d
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Nov 20 12:28:34 2020 +0100

    c++: Add __builtin_clear_padding builtin - C++20 P0528R3 compiler side
[PR88101]

    The following patch implements __builtin_clear_padding builtin that clears
    the padding bits in object representation (but preserves value
    representation).  Inside of unions it clears only those padding bits that
    are padding for all the union members (so that it never alters value
    representation).

    It handles trailing padding, padding in the middle of structs including
    bitfields (PDP11 unhandled, I've never figured out how those bitfields
    work), VLAs (doesn't handle variable length structures, but I think almost
    nobody uses them and it isn't worth the extra complexity).  For VLAs and
    sufficiently large arrays it uses runtime clearing loop instead of emitting
    straight-line code (unless arrays are inside of a union).

    The way I think this can be used for atomics is e.g. if the structures
    are power of two sized and small enough that we use the hw atomics
    for say compare_exchange __builtin_clear_padding could be called first on
    the address of expected and desired arguments (for desired only if we want
    to ensure that most of the time the atomic memory will have padding bits
    cleared), then perform the weak cmpxchg and if that fails, we got the
    value from the atomic memory; we can call __builtin_clear_padding on a copy
    of that and then compare it with expected, and if it is the same with the
    padding bits masked off, we can use the original with whatever random
    padding bits in it as the new expected for next cmpxchg.
    __builtin_clear_padding itself is not atomic and therefore it shouldn't
    be called on the atomic memory itself, but compare_exchange*'s expected
    argument is a reference and normally the implementation may store there
    the current value from memory, so padding bits can be cleared in that,
    and desired is passed by value rather than reference, so clearing is fine
    too.
    When using libatomic, we can use it either that way, or add new libatomic
    APIs that accept another argument, pointer to the padding bit bitmask,
    and construct that in the template as
      alignas (_T) unsigned char _mask[sizeof (_T)];
      std::memset (_mask, ~0, sizeof (_mask));
      __builtin_clear_padding ((_T *) _mask);
    which will have bits cleared for padding bits and set for bits taking part
    in the value representation.  Then libatomic could internally instead
    of using memcmp compare
    for (i = 0; i < N; i++) if ((val1[i] & mask[i]) != (val2[i] & mask[i]))

    2020-11-20  Jakub Jelinek  <jakub@redhat.com>

            PR libstdc++/88101
    gcc/
            * builtins.def (BUILT_IN_CLEAR_PADDING): New built-in function.
            * gimplify.c (gimplify_call_expr): Rewrite single argument
            BUILT_IN_CLEAR_PADDING into two-argument variant.
            * gimple-fold.c (clear_padding_unit, clear_padding_buf_size): New
            const variables.
            (struct clear_padding_struct): New type.
            (clear_padding_flush, clear_padding_add_padding,
            clear_padding_emit_loop, clear_padding_type,
            clear_padding_union, clear_padding_real_needs_padding_p,
            clear_padding_type_may_have_padding_p,
            gimple_fold_builtin_clear_padding): New functions.
            (gimple_fold_builtin): Handle BUILT_IN_CLEAR_PADDING.
            * doc/extend.texi (__builtin_clear_padding): Document.
    gcc/c-family/
            * c-common.c (check_builtin_function_arguments): Handle
            BUILT_IN_CLEAR_PADDING.
    gcc/testsuite/
            * c-c++-common/builtin-clear-padding-1.c: New test.
            * c-c++-common/torture/builtin-clear-padding-1.c: New test.
            * c-c++-common/torture/builtin-clear-padding-2.c: New test.
            * c-c++-common/torture/builtin-clear-padding-3.c: New test.
            * c-c++-common/torture/builtin-clear-padding-4.c: New test.
            * c-c++-common/torture/builtin-clear-padding-5.c: New test.
            * g++.dg/torture/builtin-clear-padding-1.C: New test.
            * g++.dg/torture/builtin-clear-padding-2.C: New test.
            * gcc.dg/builtin-clear-padding-1.c: New test.

  parent reply	other threads:[~2020-11-20 11:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-88101-4@http.gcc.gnu.org/bugzilla/>
2020-09-15 20:03 ` rodgertq at gcc dot gnu.org
2020-11-15 17:30 ` jakub at gcc dot gnu.org
2020-11-15 18:56 ` jakub at gcc dot gnu.org
2020-11-16  9:37 ` jakub at gcc dot gnu.org
2020-11-16 11:05 ` jakub at gcc dot gnu.org
2020-11-20 11:31 ` cvs-commit at gcc dot gnu.org [this message]
2020-11-27 10:25 ` cvs-commit at gcc dot gnu.org
2021-02-02 19:45 ` mpolacek at gcc dot gnu.org
2021-02-02 19:48 ` jakub at gcc dot gnu.org
2022-09-07 12:22 ` redi at gcc dot gnu.org
2022-09-08 18:37 ` redi at gcc dot gnu.org

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=bug-88101-4-6vSA14RQ3M@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@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).