From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 7FEB0385041F for ; Tue, 8 Dec 2020 19:50:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7FEB0385041F Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-310-SFKAa1QVMS2O3RZ8qgTbXw-1; Tue, 08 Dec 2020 14:50:51 -0500 X-MC-Unique: SFKAa1QVMS2O3RZ8qgTbXw-1 Received: by mail-qk1-f200.google.com with SMTP id u17so4865319qku.17 for ; Tue, 08 Dec 2020 11:50:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mOQ3ihxokFBnvDAMgEKbMzCmcgFIg8A0waWWvcAcqmU=; b=hcWxA2a8uHg/tpfDR22ddfIb/Yv075MEGSObDAE/PJQUA179zAaVZRL7VcAsceu5GJ tZitKiP/a2mQYwwDYTgWa6QR6NLsCYQMQM4JUuy9UQmJOzqJ3f/CY8shViG4u/dCbcIc OnSU7gWOTsTG4pQ1GxNm1tSeF5U1yyokXX44TNfZNliZVFzYtReAs+deGFV0h+jA22xA 30mUbmrVXEFw6MT4F4oeutGVjpejyNLHOjdGlZwZY5KwcGOM10JC7jSf4VyvQUiyj4G5 FpndqX804TBEcVIyZ4Bv8JwnO+KDuCiGOo5HfDYTww7Uscy2fBmh3wNsYDSlgbk3XNqr t6IQ== X-Gm-Message-State: AOAM532lGQdX8tznKVaGCWUEBS2hsGmPHYuGaEyUhfTUgfu+pKWYchQc G7aVVVBgrMAvccPuPLmROJaTzuQvzq46ZuFJ7C5K9dNh4X1K6qXKw4MKNTola2pYKD5jd3S1Umf Thm2tWjt4TS6XNi/t+w== X-Received: by 2002:a37:8586:: with SMTP id h128mr33492698qkd.241.1607457051032; Tue, 08 Dec 2020 11:50:51 -0800 (PST) X-Google-Smtp-Source: ABdhPJy2MyXBv61vFD6dPSrW4JYLnw5DvgKJRyrn3iVF23y60dw1R90tl27v+SEi84wFR8dR1iPb1A== X-Received: by 2002:a37:8586:: with SMTP id h128mr33492665qkd.241.1607457050710; Tue, 08 Dec 2020 11:50:50 -0800 (PST) Received: from [192.168.1.148] (209-6-216-142.s141.c3-0.smr-cbr1.sbo-smr.ma.cable.rcncustomer.com. [209.6.216.142]) by smtp.gmail.com with ESMTPSA id h9sm1803544qkk.33.2020.12.08.11.50.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Dec 2020 11:50:49 -0800 (PST) Subject: Re: [PATCH] Avoid atomic for guard acquire when that is expensive To: Bernd Edlinger , "Richard Earnshaw (lists)" , "gcc-patches@gcc.gnu.org" , Ramana Radhakrishnan , Nathan Sidwell , Christophe Lyon References: <8383d817-8622-4d1f-9564-8c10131db664@arm.com> <37023468-e7b3-0c38-265d-1065637e953e@redhat.com> <76600a88-7a4e-bd74-aefd-88e713a9ead9@redhat.com> <32000d0c-7286-6021-5bb0-eeb43641e5b3@redhat.com> From: Jason Merrill Message-ID: <1dd7db5c-9365-5832-8c55-ad41d3e11bdd@redhat.com> Date: Tue, 8 Dec 2020 14:50:48 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_MANYTO, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 19:50:54 -0000 On 12/7/20 11:17 AM, Bernd Edlinger wrote: > On 12/7/20 4:04 PM, Jason Merrill wrote: >> On 12/5/20 7:37 AM, Bernd Edlinger wrote: >>> On 12/2/20 7:57 PM, Jason Merrill wrote: >>>> On 12/1/20 1:28 PM, Bernd Edlinger wrote:>>>> +      tree type = targetm.cxx.guard_mask_bit () >>>>> +          ? TREE_TYPE (guard) : char_type_node; >>>>> + >>>>> +      if (is_atomic_expensive_p (TYPE_MODE (type))) >>>>> +    guard = integer_zero_node; >>>>> +      else >>>>> +    guard = build_atomic_load_type (guard, MEMMODEL_ACQUIRE, type); >>>> >>>> It should still work to load a single byte, it just needs to be the least-significant byte. >> >> I still don't think you need to load the whole word to check the guard bit. > > Of course that is also possible. But I would not expect an > address offset and a byte access to be cheaper than a word access. Fair point. > I just saw that get_guard_bits does the same thing: > access the first byte if !targetm.cxx.guard_mask_bit () > and access the whole word otherwise, which is only > there for ARM EABI. >>> And this isn't an EABI issue; it looks like the non-EABI code is also broken for big-endian targets, both the atomic load and the normal load in get_guard_bits. >>> >>> I think the non-EABI code is always using bit 0 in the first byte, >>> by using the endian-neutral #define _GLIBCXX_GUARD_BIT __guard_test_bit (0, 1). >> >> Except that set_guard sets the least-significant bit on all targets. > > Hmm, as I said, get_guard_bits gets the guard as a word if !targetm.cxx.guard_mask_bit (), > and as the first byte otherwise. Of course it could get the third byte, > if !targetm.cxx.guard_mask_bit () && BYTES_BIG_ENDIAN, but it would be more complicated > this way, wouldn't it? Ah, yes, I was overlooking that set_guard uses get_guard_bits. The patch is OK. >>> Only ARM EABI uses bit 0 in byte 3 if big-endian and bit 0 in byte 0 otherwise. >>> >>> For all other targets when _GLIBCXX_USE_FUTEX is defined, >>> __cxa_guard_XXX accesses the value as int* while the memory >>> is a 64-bit long, so I could imagine that is an aliasing violation. >>> >>> >>> But nothing that needs to be fixed immediately. >> >> Agreed. >> >>> Attached is the corrected patch. >>> >>> Tested again on arm-none-eabi with arm-sim. >>> Is it OK for trunk? >>> >>> Thanks >>> Bernd. >>> >>>> Jason >>>> >> >