From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 5A1CA3858CDB for ; Fri, 26 May 2023 13:55:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5A1CA3858CDB Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nexgo.de Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=nexgo.de Received: from mr5.vodafonemail.de ([145.253.228.165]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q2Xv3-0007VV-TA for gcc@gnu.org; Fri, 26 May 2023 09:55:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nexgo.de; s=vfde-smtpout-mb-15sep; t=1685109346; bh=EFFFP3NmYcBVEQD2rg/z12kWVFot62qs++XTy899ohA=; h=Message-ID:From:To:References:In-Reply-To:Subject:Date: Content-Type:X-Mailer:From; b=CCf7QZ2Z6DRE/6+hzrkP1qCJa4ZwmPF8hnizENIAzkIGock22V1u3+0Xk8YIQh+iy Az1Gk/rjbK9vLUgK4xHtcLurcd2b0WQH1D/VJ9AZnvrHdEc8SHiGQsH6YSN3RMln3j QNfGXwqcX2GKSEvJ0vrzWaxSOz7CnbBdPlgPiEA8= Received: from smtp.vodafone.de (unknown [10.0.0.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mr5.vodafonemail.de (Postfix) with ESMTPS id 4QSRJy3FSbz1y5s; Fri, 26 May 2023 13:55:46 +0000 (UTC) Received: from H270 (p5b38f631.dip0.t-ipconnect.de [91.56.246.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp.vodafone.de (Postfix) with ESMTPSA id 4QSRJh757Vz9s4C; Fri, 26 May 2023 13:55:29 +0000 (UTC) Message-ID: From: "Stefan Kanthak" To: "Jakub Jelinek" Cc: "Jonathan Wakely" , , "Andrew Pinski" References: <51071A92918346ABBC6B5703179F5174@H270> <896EB515110646CEBAA84E98E273E4B8@H270> <4BD5D8BA8E0F45098CC3E2B188A216E6@H270> In-Reply-To: Subject: Re: Will GCC eventually support SSE2 or SSE4.1? Date: Fri, 26 May 2023 15:49:12 +0200 Organization: Me, myself & IT MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.24158 X-purgate-type: clean X-purgate: clean X-purgate-size: 3011 X-purgate-ID: 155817::1685109342-047F74DE-5C283BFA/0/0 Received-SPF: pass client-ip=145.253.228.165; envelope-from=stefan.kanthak@nexgo.de; helo=mr5.vodafonemail.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,DKIM_VALID_EF=-0.1,RCVD_IN_DNSWL_LOW=-0.7,SPF_HELO_NONE=0.001,SPF_PASS=-0.001,T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_FAIL,SPF_HELO_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: "Jakub Jelinek" wrote: > On Fri, May 26, 2023 at 02:19:54PM +0200, Stefan Kanthak wrote: >> > I find it very SURPRISING that you're only just learning the basics of >> > how to use gcc NOW, after YELLING about all the OUCH. >> >> I'm NOT surprised that you don't grok it! >> >> gcc -msse4.1 -m32 -march=core2 ... >> >> Which -m* options win here? >> Do -m32 or -march=core2 override -msse4.1? > > Jonathan told you what to use to find it out (-Q --help=target). > -m32/-m64/-mx32/-m16 options don't affect the ISA, they switch the > main ABI (ilp32 32-bit code, lp64 64-bit code, ilp32 code running > in 64-bit mode, 16-bit code). PLEASE read your own documentation and specify ANY: | -m32 ... | generates code that runs on any i386 system. The first example of my initial posts falsifies "runs on any i386 system"! > -march= options selects the ISA base (which CPU family to compile form > as minimum), if you don't supply it, the default from how gcc has been > configured is selected (e.g. if you configure --with-arch-32=core2, then > that will be the -m32 default, if you configure --with-arch=x86-64, that > will be the -march default if --with-arch-32= isn't specified, etc.). > If more than one -march= is specified, the last one wins. But "the last one wins" does NOT apply to -m32 or -m: the latter are additive, INDEPENDENT from their position before or after -march=, what is NOT documented, and -m32 fails to disable all -m not common to ANY i386 system set before, thus contradicting the documentation. > And, the -mISA options then tweak the ISA set. Most ISAs have dependencies, > say -msse4.1 enables -mssse3 which enables -msse3 which enables -msse2 etc., > and similarly the -mno-ISA options disable what ISAs depend on it, so > -mno-avx disables -mno-avx2 which disables -mno-avx512f which disables ... These points are obvious. NOT obvious is but that -m -march= does not clear any not supported in , i.e the last one does NOT win here. JFTR: because -m32 -mtune=i386 disables SSE instructions I made the wrong assumption "-mtune=native is the default", upon which (not only) you reacted like your compiler when it encounters UB and stopped reading. > -mtune= option specifies for which CPU family the code should be tuned, > it will still run on any code compatible with the implicit or explicit > -march=, but will schedule instructions or choose from alternative forms > from the selected ISAs to perform best on the -mtune= family. The third example of my initial post disables SSE2 with -mtune=i386, but does NOT "perform best" on the i386 family: before the corei all i386 CPUs run MOV , plus AND , slower than AND ,, i.e. the code generated with -mtune=i586 performs best. JTFR: my post is NOT about "How to use GCC", it's about the not properly optimised code. Stefan