From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) by sourceware.org (Postfix) with ESMTPS id 7D46E3858D38 for ; Tue, 22 Aug 2023 13:02:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7D46E3858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-yb1-xb2f.google.com with SMTP id 3f1490d57ef6-d7225259f52so4486096276.0 for ; Tue, 22 Aug 2023 06:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692709362; x=1693314162; 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=BxCw8qjKs+6akQq1y96xNMpQyTV0+hmUYHvbudU4rb4=; b=eTyumZbD6KGytAFKBNKCXCtq91PRb2yUqFtjOQZiWKLLLgzEMWrImO5RFpw+smRxMn FDGVkY7po1SRkvWQX1PEOq7ljYoinF9TEC83Dc6LcLqMMonMssNdQnfK3pkg059Bll0U loqYZjQMWr3dAg23oaz6a7hXBOTR6VLbwPUcHja3gzJua2dpauhDAobrHy3kvuOv6aiR Vz8J4atUCBa71tt9+0cfjiust4NsGRSe749vacnfurjI1gzAhsAeVkrE0WYAvlIj1OvZ amnUPy16giykE+BAn24s+QXrrTx7t1GB93S/wF1W693tRY5l0U0Uib2CsB76P6TVOeBR BbLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692709362; x=1693314162; 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=BxCw8qjKs+6akQq1y96xNMpQyTV0+hmUYHvbudU4rb4=; b=eHRSnCB756k1WZM/iQ8JtVkLFzV9SszE4nORQzPJvmSeUJ1TtMHb5kqS8FNy74Yqyy m5YbrQXARpU1YXq0sPODBfWL94TBudOqO1eJDi3nqa8/cGbDmVVG/DPHlzsqyKmkZjuV xcaVHMvJ1Cses0JjIbvpTAe8xs0SUy9C607NT1R1fP89Xws2k25ml0/RcmkOtr9/BM8Q BMIb9PC9d6nf/1jcoBrvw8kqX1pPMKisBnNW6eQtCepsJ5uuZN5MDdddHzmDFDO2BGiI ViR5ejpOMUS48FtPRSbRAltQ+J6Hi/uwsKxRmKJsGCHOCzsIC4Cusnp1A3sMBQc4KV6z 220Q== X-Gm-Message-State: AOJu0YzxU+vOACI2qkl3IxH11AhQB/jYcIsrkverIGnKtwcV/4JA6NfH bj39/laBGL/08PmCOTTy7/U6osQVYb/AiIIXPac= X-Google-Smtp-Source: AGHT+IHQPjxCFZyUWk3fgvOObEEUIhaDkQpyidh2FizvEwXzfhMV0uGgb3cGmMpvikDT7k22A00Z/r3ICfBi2t4X4lk= X-Received: by 2002:a81:a1c1:0:b0:589:8b55:f7f7 with SMTP id y184-20020a81a1c1000000b005898b55f7f7mr7570601ywg.39.1692709361657; Tue, 22 Aug 2023 06:02:41 -0700 (PDT) MIME-Version: 1.0 References: <20230808071312.1569559-1-haochen.jiang@intel.com> In-Reply-To: From: Hongtao Liu Date: Tue, 22 Aug 2023 21:02:29 +0800 Message-ID: Subject: Re: Intel AVX10.1 Compiler Design and Support To: Jakub Jelinek Cc: Richard Biener , "Jiang, Haochen" , ZiNgA BuRgA , "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 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 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, Aug 22, 2023 at 4:34=E2=80=AFPM Jakub Jelinek wr= ote: > > On Tue, Aug 22, 2023 at 09:36:15AM +0200, Richard Biener via Gcc-patches = wrote: > > I think internally we should have conditional 512bit support work acros= s > > AVX512 and AVX10. > > > > I also think it makes sense to _internally_ have AVX10.1 (10.1!) just > > enable the respective AVX512 features. AVX10.2 would then internally > > cover the ISA extensions added in 10.2 only. Both would reduce the > > redundancy and possibly make providing inter-operation between > > AVX10.1 (10.1!) and AVX512 to the user easier. I see AVX 10.1 (10.1!) > > just as "re-branding" latest AVX512, so we should treat it that way > > (making it an alias to the AVX512 features). > > > > Whether we want allow -mavx10.1 -mno-avx512cd or whether > > we only allow the "positive" -mavx512f -mavx512... (omitting avx512cd) > > is an entirely separate > > question. But I think to not wreck the core idea (more interoperabilit= y, > > here between small/big cores) we absolutely have to > > provide a subset of avx10.1 but with disabled 512bit vectors which > > effectively means AVX512 with disabled 512bit support. > > Agreed. And I still think -mevex512 vs. -mno-evex512 is the best option > name to represent whether the effective ISA set allows 512-bit vectors or > not. I think -mavx10.1 -mno-avx512cd should be fine. And, -mavx10.1-256 > option IMHO should be in the same spirit to all the others a positive ena= blement, > not both positive (enable avx512{f,cd,bw,dq,...} and negative (disallow > 512-bit vectors). So, if one uses -mavx512f -mavx10.1-256, because the > former would allow 512-bit vectors, the latter shouldn't disable those ag= ain > because it isn't a -mno-* option. Sure, instructions which are specific = to But there's implicit negative (disallow 512-bit vector), I think -mav512f -mavx10.1-256 or -mavx10.1-256 -mavx512f shouldn't enable 512-bit vector. Further, we should disallow a mix of exex512 and non-evex512 (e.g. -mavx10.1-512 -mavx10.2-256),they should be a unified separate switch that either disallows both or allows both. Instead of some isa allowing it and some isa disallowing it. > AVX10.1 (aren't present in any currently existing AVX512* ISA set) might = be > enabled only in 128/256 bit variants if we differentiate that level. > But, if one uses -mavx2 -mavx10.1-256, because no AVX512* has been enable= d > it can enable all the AVX10.1 implied AVX512* parts without EVEX.512. > > Jakub > --=20 BR, Hongtao