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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id E3973389041F for ; Tue, 12 Jan 2021 14:22:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E3973389041F Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-149-vWhYtFYPMgK0C19CR4SZYg-1; Tue, 12 Jan 2021 09:22:50 -0500 X-MC-Unique: vWhYtFYPMgK0C19CR4SZYg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 263DA8144E1; Tue, 12 Jan 2021 14:22:49 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-114-67.ams2.redhat.com [10.36.114.67]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 73CA47046A; Tue, 12 Jan 2021 14:22:48 +0000 (UTC) From: Florian Weimer To: Jonathan Wakely Cc: =?utf-8?Q?=E2=98=82Josh_Chia_=28=E8=AC=9D=E4=BB=BB=E4=B8=AD=29_via_Gcc?= =?utf-8?Q?-help?= Subject: Re: Failure to optimize? References: <8735z6i8fn.fsf@oldenburg2.str.redhat.com> Date: Tue, 12 Jan 2021 15:22:46 +0100 In-Reply-To: (Jonathan Wakely's message of "Tue, 12 Jan 2021 14:20:35 +0000") Message-ID: <87h7nmgrpl.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, 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-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 14:22:56 -0000 * Jonathan Wakely: > On Tue, 12 Jan 2021 at 13:37, Florian Weimer via Gcc-help > wrote: >> >> * =E2=98=82Josh Chia (=E8=AC=9D=E4=BB=BB=E4=B8=AD) via Gcc-help: >> >> > I have a code snippet that I'm wondering why GCC didn't optimize the w= ay I >> > think it should: >> > https://godbolt.org/z/1qKvax >> > >> > bar2() is a variant of bar1() that has been manually tweaked to avoid >> > branches. I haven't done any benchmarks but, I would expect the branch= less >> > bar2() to perform better than bar1() but GCC does not automatically >> > optimize bar1() to be like bar2(); the generated code for bar1() and b= ar2() >> > are different and the generated code for bar1() contains a branch. >> >> The optimization is probably valid for C99, but not for C11, where the >> memory model prevents the compiler from introducing spurious writes: >> Another thread may modify the variable concurrently, and if this happens >> only if foo returns NULL, the original bar1 function does not contain a >> data race, but the branchless version would. > > I'm not sure about the rules for C, but in C++ the compiler can assume > there is no race, because the increment is not atomic. The problem is that the store is conditional as written. The compiler cannot introduce an unconditional store due to that. Thanks, Florian --=20 Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'N= eill