From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by sourceware.org (Postfix) with ESMTPS id F367C3858C2A for ; Tue, 12 Dec 2023 12:16:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F367C3858C2A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F367C3858C2A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::133 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702383371; cv=none; b=SHg5KYa0heftMA70eyvcCK49Ta0/Z58fGFfqn0BzprapEB5eQFtvqWIPb33N32PqbipgPu0gLHkIqtdwR8s4xJT1MWtjZKdAIxofpHGZdXmieRBsgoPuxUFgcYS/EQ9UIJIPuffnNXg7wfPj9NDcSfmDgiPQ3OPCV15C/WMXN+I= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702383371; c=relaxed/simple; bh=/IysPwkxVMmqnUuMMDNAUHozZVwdGOLRkMZ0DfVjlmo=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=lDsn26jT10Y5DItMCWd/MR8QHDfAzpOwkJGby+64r//f172nUZfr6r+RSYkGw4kVbrF+tVuOD9ffQ0WMCZsLt4OSooBJcJ83XstAWX1V+3YzYAGjL10fa09NwGKn9KI6y2mxgdDupJ3/jvgsc9dZpIyjmQwV2XT/JShdLx8yU5E= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-50be58a751cso6375812e87.2 for ; Tue, 12 Dec 2023 04:16:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702383368; x=1702988168; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=M0u/2AXsAOmLBFVFhTmpsZisXb5SUVP7myTjTO3OjqM=; b=aCB42HIwz4fO/Q4oW25EcRHBuUziZUzIZU+IT7PRT1itHEqJlEUE12IZhCe5BD+z5t xcBa8MsUo5uviKNYlzLt+aPdQ0DfnqlQSWo3th2W3JU8IppdOuQNFS0fqxfUjnr5WtbS I0DBdOvqbJiVCvi7j7or7M6j8N3cQwTbAYqL4O2YSi3P9pvekHvP3jEO+CEKIM30D8rj bSDS22qt/Ve07OKgi/0J6kjd+OC0+5ETw9Q1LQj7UyKJYh7GTk9nKSFeyGbVcHoCX88D i77huXb7cIRbnLJbcsWeW3Ybz3x7IH57k55bOmHz0M+sqLzgd5dFVO73zWsJdCAB32aN 3ebA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702383368; x=1702988168; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=M0u/2AXsAOmLBFVFhTmpsZisXb5SUVP7myTjTO3OjqM=; b=F3BNWYv1Fp2jMSAoMmRJLZkS3AayL/lllpb5HB92VJFnEh0c/LhGOPZXgP9DCrl69j 0DJzNvfUqjtkaYjnTlrwtS01D/LL7XfKxxkBjGUDsDNq2JfzbpssOvcN1zqVz8GMOkz6 qtLnilqU2Jn3gZUdFt1hzcV9NWGRB7rcKVjxuo83a2dvBn6ggPe6Rvhbk5ROzOCPj/SW 7DXnYm44pWxeT8Gbq5Hj3z6BEXDxi9da5t6i9TN9stDrFjH0mPaoDQxAnaQpqdEI91fW Vbw9oqKLa161waieaA8PY16dsIrkUACfiyZhfoXySd/Iaa9nnRiQ27yoRF6un49pzMq5 33/A== X-Gm-Message-State: AOJu0YxJRP2jSURE4xkoJUoDFGOcbai1y2AYKjiYw7DLjP2DqotjnZmi D4LdO6Um+Eaj69hFILbmbVKZPi8gYfIjS0LzL4Y= X-Google-Smtp-Source: AGHT+IFmQueifVPJxDA5VKRPY08qPqZCmtS4faa8KO8r+lHd4lPwvOPYjgke5R2U6M3+HUfUzJ2rFJ0GFP5Cjr3pgyI= X-Received: by 2002:a19:8c02:0:b0:50b:fcdb:8df5 with SMTP id o2-20020a198c02000000b0050bfcdb8df5mr2390520lfd.24.1702383368238; Tue, 12 Dec 2023 04:16:08 -0800 (PST) MIME-Version: 1.0 References: <20231110014158.371690-1-haochen.jiang@intel.com> <87cyvbn63u.fsf@oldenburg.str.redhat.com> In-Reply-To: <87cyvbn63u.fsf@oldenburg.str.redhat.com> From: Richard Biener Date: Tue, 12 Dec 2023 13:14:54 +0100 Message-ID: Subject: Re: [RFC] Intel AVX10.1 Compiler Design and Support To: Florian Weimer Cc: Hongtao Liu , Haochen Jiang , gcc-patches@gcc.gnu.org, hongtao.liu@intel.com, ubizjak@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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: On Tue, Dec 12, 2023 at 10:05=E2=80=AFAM Florian Weimer wrote: > > * 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. Indeed it does, enabling avx256_optimal everywhere, but enabling 512bit moves on Sapphire Rapids (and not Granite Rapids!?). > That's not true for the > default tuning for -march=3Dx86-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. The corner Intel painted itself to be in is that their small cores on the hybrid consumer products only support 128bit native (256bit emulated) and their data-center "small core" SKU doesn't fare any better there. That's the reason their marketing invented AVX10 which will allow the AVX512 ISA play "nice" with a smaller data path (but I'm sure, or at least I hope, that actual implementations will have a native 256bit data path and not emulate it via 128bit). The current problem is that the castrated consumer SKUs cannot use EVEX at all and in the future will be crippled to 256bits. So that will be the common thing to target when targeting EVEX support across Intel/AMD - use 256bit only. Note that AVX10 excludes Zen4 which lacks support for two niche AVX512 ISA extensions. > 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. True, there isn't even widespread VEX adoption yet ... and now there's APX as the next best thing to target. That said, my main point was that x86-64-v4 is "broken" as it appears as a dead end - AVX512 is no more, the future is AVX10, but yet we have to define x86-64-v5 as something that includes x86-64-v4. So, can we un-do x86-64-v4? Richard. > Thanks, > Florian >