From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) by sourceware.org (Postfix) with ESMTPS id 6469F3858D28 for ; Wed, 6 Jul 2022 19:56:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6469F3858D28 Received: by mail-oi1-x229.google.com with SMTP id i3so21027600oif.13 for ; Wed, 06 Jul 2022 12:56:48 -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=fIGh2oucGDyXdi4meQHEFl7YLpdbjHGwEy8wCOkOii4=; b=LyGIM5h0d7zmDFkSvIiUzFh187h+yF5ADa6zZrDIDodq1dTp1Gu5/w8fzrzsjpBfpf Nad8SmhOcT2R1Kex+SHC3TopF2oxcI4LKnJzu5sXOoWf/9HTniH9zkn7dRAIxoHAmfXx h9V3OklzyWY5mZ1X5Cz1KpnRA3Ha+j8Nh13DPShUey5SQJ2XWEdXpy8KAawHnBpNgb9A GPzhkfqks6O9XfMQWYUA535gP23zTCHINmsALD8jVhxRP1yrqhtDutvVbbIOqusNE1Jd JvETt2OtVTLo1GL/1tdUsjPIjG65TPCSoHRGBY0ffGLAM16+H3asIJ7uggjWJxMckJ1a Ld1w== X-Gm-Message-State: AJIora+6XKrfk1e1OSASZgOy8R+rey78lri3PTvjRacjikHtBACfh3gb ho+AuNaxyK4Dsecnt0g4tXnnUakgv/IwyYUuV3qt+DHg X-Google-Smtp-Source: AGRyM1un37NL3K0lOVNhYBTcgY8vkGaLYEoNazdLoQvZJNFVHP23QMgTsLjs+vI3CIc8jOCHVl8aoHVAC3HtLE47Lj8= X-Received: by 2002:a05:6808:170b:b0:335:1807:e4a2 with SMTP id bc11-20020a056808170b00b003351807e4a2mr179013oib.89.1657137407721; Wed, 06 Jul 2022 12:56:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Noah Goldstein Date: Wed, 6 Jul 2022 12:56:36 -0700 Message-ID: Subject: Re: [PATCH 3/7] Remove atomic_bit_set/bit_test_set To: Wilco Dijkstra Cc: GNU C Library Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.3 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:56:49 -0000 On Wed, Jul 6, 2022 at 12:51 PM Noah Goldstein wrote: > > On Wed, Jul 6, 2022 at 12:37 PM Wilco Dijkstra wrote: > > > > Hi Noah, > > > > > 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. > > > > This was only one use in GLIBC so how does adding a private macro help other > > software? This idiom doesn't appear common, particularly with a non-constant bit, > > but in principle the compiler could be fixed so that it optimizes do_atomic_or2/3 > > as well. > > The usage in this patch is fine. Just seems having an internal API for > it provides > value given that in the future there may be a need for atomic_bit_set > w.o a constant > bit and there are non-obvious tricks necessary for doing it right. Also think frankly the API "atomic_bit_set" provides readability value that is lost when you expand it. The fetch_or_acquire seems like an implementation detail of the desired functionality. > > > > > > Cheers, > > Wilco