From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=9ahT=BR=m.gmane-mx.org=gcg-devel-2@sourceware.org>
Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214])
	by sourceware.org (Postfix) with ESMTPS id C92763858D38
	for <gcc@gcc.gnu.org>; Sun, 28 May 2023 12:29:50 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C92763858D38
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=hesbynett.no
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=m.gmane-mx.org
Received: from list by ciao.gmane.io with local (Exim 4.92)
	(envelope-from <gcg-devel-2@m.gmane-mx.org>)
	id 1q3FWv-0004Kf-H0
	for gcc@gcc.gnu.org; Sun, 28 May 2023 14:29:49 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: gcc@gcc.gnu.org
From: David Brown <david.brown@hesbynett.no>
Subject: Re: Who cares about performance (or Intel's CPU errata)?
Date: Sun, 28 May 2023 14:29:42 +0200
Message-ID: <u4vhfm$msc$1@ciao.gmane.io>
References: <23A490318B7149D88618A7CDA2CEDB14@H270>
 <CA+=Sn1nrDBd-LN-rY0E=a4Q_kRu5E0Gh4n-THjxhgvn3n2m0pQ@mail.gmail.com>
 <8DB226CF451A4430A8D7D5CBFE6B3972@H270>
 <CA+=Sn1nPyYf8s9Z8QtL3n_mZyH3f+xg3o5icHKMkUn_VRezkbQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.1
Content-Language: en-GB
In-Reply-To: <CA+=Sn1nPyYf8s9Z8QtL3n_mZyH3f+xg3o5icHKMkUn_VRezkbQ@mail.gmail.com>
X-Spam-Status: No, score=-3029.7 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,LIKELY_SPAM_BODY,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <gcc.gcc.gnu.org>

On 28/05/2023 01:30, Andrew Pinski via Gcc wrote:
> On Sat, May 27, 2023 at 3:54 PM Stefan Kanthak <stefan.kanthak@nexgo.de> wrote:
>>

>>          sete    al
>>          movzx   eax, al                  # superfluous
> 
> No it is not superfluous, well ok it is because of the context of eax
> (besides the lower 8 bits) are already zero'd but keeping that track
> is a hard problem and is turning problem really. And I suspect it
> would cause another false dependency later on too.
> 
> For -Os -march=skylake (and -Oz instead of -Os) we get:
>          popcnt  rdi, rdi
>          popcnt  rsi, rsi
>          add     esi, edi
>          xor     eax, eax
>          dec     esi
>          sete    al
> 
> Which is exactly what you want right?
> 
> Thanks,
> Andrew
> 
There is also the option of using "bool" as the return type for boolean 
functions, rather than "int".  When returning a "bool", gcc does not add 
the "movzx eax, al" instruction.  (There are some circumstances where 
returning "int" for a boolean value is a better choice, but usually 
"bool" makes more sense, and it can often be a touch more efficient.)

David