From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id B706F386F430 for ; Tue, 12 Jan 2021 14:20:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B706F386F430 Received: by mail-wm1-x32b.google.com with SMTP id k10so2047648wmi.3 for ; Tue, 12 Jan 2021 06:20:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3be6/xeGTSdQO8Pmn793uh/2XzmAL+a0KihEc4e3zWE=; b=mMv6xecU9mdM4KsTmvIhBqP6ah38BG3TNO3qO20AF3SVLcLvNIYnwl2kCGGAT66/2U F2C0YyaqgowTKSmRYOkVJ19WdcMiZLiQmT0h4YxG8rqQAg5eYNfyANHdB3QLnj9FSCMe sdTYc+dESecHxoUPz0ZfjzzNOza3jBdG+SviL4ByKDQrWi2SxzUSus727G4ev6992cRB ZkVTeOj7pExOIbttefKCQ65g3lmDWxs2fEFb8jviMIbBEQHpO2/j2ylEQR7sX6198ja3 ZY2PbOlE15vkGoGQOf1MU66gNIEVguL+Vc9Gl9s3BX8OuJaOmdqQhkW8wYEurTGX71u2 NHVw== X-Gm-Message-State: AOAM530yiiH9kJB8nJlOobBKxuNGDebdj2QQAK9Tr6Vca8H0KlnHX4NL Pi7DKPK02ZwD1xaDxgLg6d8KbpSQQH8VHMjSqN4= X-Google-Smtp-Source: ABdhPJzZjfSiv0vkEhj5Qvm2BJcZ9wyhgMzNsa1EASulv+IUzjvHzVlqgbjfnre5QtY3IDAy/27yrcn0639Sh7wNJ3w= X-Received: by 2002:a1c:6a10:: with SMTP id f16mr3834381wmc.106.1610461246814; Tue, 12 Jan 2021 06:20:46 -0800 (PST) MIME-Version: 1.0 References: <8735z6i8fn.fsf@oldenburg2.str.redhat.com> In-Reply-To: <8735z6i8fn.fsf@oldenburg2.str.redhat.com> From: Jonathan Wakely Date: Tue, 12 Jan 2021 14:20:35 +0000 Message-ID: Subject: Re: Failure to optimize? To: Florian Weimer Cc: =?UTF-8?B?4piCSm9zaCBDaGlhICjorJ3ku7vkuK0pIHZpYSBHY2MtaGVscA==?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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:20:49 -0000 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 wa= y 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 branchl= ess > > bar2() to perform better than bar1() but GCC does not automatically > > optimize bar1() to be like bar2(); the generated code for bar1() and ba= r2() > > 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. If there were another access to the variable then a non-atomic store would be a race even in the bar1 version.