From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by sourceware.org (Postfix) with ESMTPS id 352303857C5D for ; Wed, 6 Jul 2022 19:30:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 352303857C5D Received: by mail-pj1-x102d.google.com with SMTP id v4-20020a17090abb8400b001ef966652a3so6949335pjr.4 for ; Wed, 06 Jul 2022 12:30:45 -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; bh=eBNydeZFABboQ2j5ba3KwaVjAm6vStBdl0hzqRr4hGk=; b=Y5tquLaoEqBW40G+d6dPcY1Oz0TvOd5l79EnexwC6M3h7wmNLrB67mdLSZXyBSvFsE q5erOMsQZrnXpA3r7miAJPE+50ikVKt+RNj/WI220czAQG1XnufupTtblOy4MC+1ADv4 RZXCPfYe3HSJPCprgLcUQe+ioEI68Orj+g6vYZChdQ8CsSV8ZBaUjtOpyzjzZ8536sqp 77abHifreUAkecLBQDb5KBqNf4752OGCy5V6Z/86VCTLPsvHgpnJS7f+lyWFPe/PU9jd Onornp+BYdfI5uJ0LX8dX9zXabz8mLQag/oh0NDfA7dyrMZgG6hPlynCJxfYHYOtT1K1 SmMA== X-Gm-Message-State: AJIora+R66cnoz0WarGB4bntv0K7MzONXKiDNZRuhyH7p8YepT7qwaYS 7aXhLmHz+JlVICtQYTBwaoxKVIi8Clvpe7DLS7GPEZqD X-Google-Smtp-Source: AGRyM1s5aCE55d2/zH6Y1+DWDHx+ZMrGw3E5u4vF08adi3lTQKJQYD9Hh+mS5UtTybjiFGHK60oonjJx6osx8UFV4+c= X-Received: by 2002:a17:902:d505:b0:16b:fbd1:9f51 with SMTP id b5-20020a170902d50500b0016bfbd19f51mr7404147plg.149.1657135844080; Wed, 06 Jul 2022 12:30:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "H.J. Lu" Date: Wed, 6 Jul 2022 12:30:08 -0700 Message-ID: Subject: Re: [PATCH 3/7] Remove atomic_bit_set/bit_test_set To: Noah Goldstein Cc: Wilco Dijkstra , GNU C Library Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3018.6 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: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2022 19:30:46 -0000 On Wed, Jul 6, 2022 at 12:15 PM Noah Goldstein via Libc-alpha wrote: > > On Wed, Jul 6, 2022 at 12:00 PM Wilco Dijkstra wrote: > > > > Hi Noah, > > > > > > - if (atomic_bit_test_set (&pd->cancelhandling, TERMINATED_BIT) == 0) > > > > + if ((atomic_fetch_or_acquire (&pd->cancelhandling, 1 << TERMINATED_BIT) > > > > + & (1 << TERMINATED_BIT)) == 0) > > > > > Can these remain macros that setup the bit_test_set properly but > > > use compiler intrinsics? > > > > The fetch_or above is already written in a way that allows GCC to recognize it > > (it's identical to your do_atomic_or0), so I don't see any issue here. However > > there is a TERMINATED_BITMASK which might make it more readable. > > For non-constant shift values it needs to be like atomic_or4/atomic_or5. > > Since this needs to be set up in a particular way it seems worth it to > keep it as a macro that will do it properly. Fine with replacing the underlying > atomic op with a compiler intrinsic. GCC can optimize some atomic operations to locked bit operations. Have we checked if the new assembly codes are as efficient as the old ones on x86-64? -- H.J.