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 [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id D7A53385BAC4 for ; Tue, 12 Dec 2023 09:05:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D7A53385BAC4 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D7A53385BAC4 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702371942; cv=none; b=SK9GnipxUHwMzXFG9MJFjR1+pE8m3v9GSg97zF594oujXiAWAXdm0wtRuHpIUZdXJLBu4XnQ9d5MtsJ6KdNQdSwWoY+XJ+S7wiGD7KcFEhuKAD/L1CVLitUO600NjcoSyADbxEIl2uMvFUMCdtyGoxjWf9NQBvQAjDgWDvNQRxE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702371942; c=relaxed/simple; bh=354I0kJSpWW87EIekVyHPKUOAa1Hfqwbg3PhuCKU5JA=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=Zdue0pNzvdL9LSWEH2qU9632C8fCnblhf7IcbBF/swbIKkk38fu1EHdWPJleT2pzquUdFvCKj4LWwqIlW2UdO+r2IVbcYPwJ6mTsDAK5vM4z34OGafUYhdVaZTmZL3bu6S9CKB7R4vSi1s0HUy9zqQBbesycikyq6JxYa671tPc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702371931; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fbq+l5M/EV0WCn+F/WQcjSnqdngp6YK9niANfkR0RaY=; b=PQH92feytzTg0yuBJcRYjm3qPuFfl5u8EhhW1/hF4HZS1GYFroSRBsY4bIjvu5Njt0LMEi Csra9/rOjpfkwEPhe21L/i5YS/XC8lzpK4kWlomPonfKB6I34xjJBVNuoehyNYZOx/uywj Amq/jAKGNnGht5ODe1Yo7VEVR745XSI= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-227-KcI1egMiOpya-ZdUwUdj3g-1; Tue, 12 Dec 2023 04:05:29 -0500 X-MC-Unique: KcI1egMiOpya-ZdUwUdj3g-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 573EC88B782; Tue, 12 Dec 2023 09:05:29 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.100]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 927BF51E3; Tue, 12 Dec 2023 09:05:27 +0000 (UTC) From: Florian Weimer To: Richard Biener Cc: Hongtao Liu , Haochen Jiang , gcc-patches@gcc.gnu.org, hongtao.liu@intel.com, ubizjak@gmail.com Subject: Re: [RFC] Intel AVX10.1 Compiler Design and Support References: <20231110014158.371690-1-haochen.jiang@intel.com> Date: Tue, 12 Dec 2023 10:05:25 +0100 In-Reply-To: (Richard Biener's message of "Mon, 13 Nov 2023 12:25:41 +0100") Message-ID: <87cyvbn63u.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Richard Biener: > If it were possible I'd axe x86_64-v4. Maybe we should add a x86_64-v3.5 > that sits inbetween v3 and v4, offering AVX512 but restricted to 256bit > (and obviously not requiring more of the AVX512 features that v4 > requires). As far as I understand it, GCC's Intel tuning for AVX-512 is leaning heavily towards 256 bit vector length anyway. That's not true for the default tuning for -march=x86-64-v4, though, it prefers 512 bit vectors. I've seen third-party reports that AMD Zen 4 does better in some ways with 512 bit vectors than with 256 bit vectors (despite its 256-bit-wide execution ports), but I have not tried to verify these observations. Still, this suggests that restricting a post-x86-64-v3 level to 256 bit vectors may not be an easy decision. On the other hand, a new EVEX-capable level might bring earlier adoption of EVEX capabilities to AMD CPUs, which still should be an improvement over AVX2. This could benefit AMD as well. So I would really like to see some AMD feedback here. There's also the matter that time scales for EVEX adoption are so long that by then, Intel CPUs may end up supporting and preferring 512 bit vectors again. Thanks, Florian