From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) by sourceware.org (Postfix) with ESMTPS id EC5463854822 for ; Tue, 22 Aug 2023 13:35:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EC5463854822 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-xb30.google.com with SMTP id 3f1490d57ef6-d743f58050bso3920825276.1 for ; Tue, 22 Aug 2023 06:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692711357; x=1693316157; 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=En5lCMbEf7jl0/zOqiBZYsE26UC7ZOXprHfVNer5wy4=; b=J3hKHY174Ol1KrEwNKV5PifWTTIm4NSVziYlHAwsymfAS58s6iLSbTm180evAkKRO/ EoqfYbCFdZmCkcv3273ZrWdLKBDQOPRD8GnmMqPIlfLCfFOk68NJImnsaEIFIIUKp7oH PxkKZPz6gGLSBEvJ3eWDf6kCEVo6GKmAiW/CxBXNbhI5yhdzKyszg+etAZqUJfUrMfap bBoBl3uoksZ46G3ysEKZOapZGBGy5EtQ+5LWsOlGWAUgJqE+Xi6Hyz5YyWr1TZZQ0KMS A/mc0+6Ikh80woJ1beNiIDPBU+eIT80X2RWRgfDT1ye0RIxfeGWzum6tqN6un0VlwFpO uSdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692711357; x=1693316157; 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=En5lCMbEf7jl0/zOqiBZYsE26UC7ZOXprHfVNer5wy4=; b=XLvAOtLk5VXq7XI4fj7rd/R0tQqdM3BghIg67b97zLeFs/Aci96Jgv89tVa/uI9Kbt BLYMJGMfaskifgWkC/VMY75IBMYlC5vOgflGmkNcK8lYrGGC5pc2o0QnHK3/kwYWzNbC WjUMrfUh0jfHfc+OOOeouy3FbnsfQ8q9rKmqei/vUBgFtXs+y2FY4L9DT8DN+/i5o5Wx yM1wn/y7I/z7NkMYsTJopwBPoYcAsE8H1IC67f7dP8OYDj8LVgNRoOLeboz9SoiZyW9I /nZI/6kHb9g6t4fE3ub1+/UbiDD9QkiFqWx/WBGrDXcsgrNzFl+1OdL1QlNGrm6eJPge 5hug== X-Gm-Message-State: AOJu0YxVO62f8+Ntr2u364Ls88CaMRp3wF8LxyRCd4jIKCKAIp8bK5I/ IyvbiyOKE2bD9IFptCXqd4NgyJfTp0kW8U7/a78= X-Google-Smtp-Source: AGHT+IGGBP6/I1yqrENHYJCuYZEZ4NY8+sw8HFXYB1Io7X73IHXCgUiNbz9tJOw92wtzzOb1EkTW5CpzDSjb3uGfvro= X-Received: by 2002:a25:d207:0:b0:d08:2101:562d with SMTP id j7-20020a25d207000000b00d082101562dmr9835658ybg.34.1692711356946; Tue, 22 Aug 2023 06:35:56 -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:35:44 +0800 Message-ID: Subject: Re: Intel AVX10.1 Compiler Design and Support To: Richard Biener Cc: Jakub Jelinek , "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.8 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 9:24=E2=80=AFPM Richard Biener wrote: > > On Tue, Aug 22, 2023 at 3:16=E2=80=AFPM Jakub Jelinek = wrote: > > > > On Tue, Aug 22, 2023 at 09:02:29PM +0800, Hongtao Liu wrote: > > > > Agreed. And I still think -mevex512 vs. -mno-evex512 is the best o= ption > > > > name to represent whether the effective ISA set allows 512-bit vect= ors 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 positi= ve enablement, > > > > not both positive (enable avx512{f,cd,bw,dq,...} and negative (disa= llow > > > > 512-bit vectors). So, if one uses -mavx512f -mavx10.1-256, because= the > > > > former would allow 512-bit vectors, the latter shouldn't disable th= ose again > > > > because it isn't a -mno-* option. Sure, instructions which are spe= cific to > > > But there's implicit negative (disallow 512-bit vector), I think > > > > That is wrong. > > > > > -mav512f -mavx10.1-256 or -mavx10.1-256 -mavx512f shouldn't enable > > > 512-bit vector. > > > > Because then the -mavx10.1-256 option behaves completely differently fr= om > > all the other isa options. > > > > We have the -march=3D options which are processed separately, but the n= ormal > > ISA options either only enable something (when -mwhatever), or only dis= able something > > (when -mno-whatever). -mavx512f -mavx10.1-256 should be a union of thos= e > > ISAs, like say -mavx2 -mbmi is, not an intersection or something even > > harder to understand. > > > > > 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. > > > > No, it will be really terrible user experience if the new options behav= e > > completely differently from everything else. Because then we'll need t= o Ok, then we can't avoid TARGET_AVX10_1 in those existing 256/128-bit evex instruction patterns. > > document it in detail how it behaves and users will have hard time to f= igure > > it out, and specify what it does not just on the command line, but also= when > > mixing with target attribute or pragmas. -mavx10.1-512 -mavx10.2-256 s= hould > > be a union of those two ISAs. Either internally there is an ISA flag w= hether > > the instructions in the avx10.2 ISA but not avx10.1 ISA can operate on > > 512-bit vectors or not, in that case -mavx10.1-512 -mavx10.2-256 should > > enable the AVX10.1 set including 512-bit vectors + just the < 512-bit > > instructions from the 10.1 to 10.2 delta, or if there is no such separa= tion > > internally, it will just enable full AVX10.2-512. User has asked for i= t. > > I think having all three -mavx10.1, -mavx10.1-256 and -mavx10.1-512 is ju= st > confusing. Please separate ISA (avx10.1) from size. If -m[no-]evex512 i= sn't > good propose something else. -mavx512f will enable 512bits, -mavx10.1 > will not unless -mevex512. -mavx512f -mavx512vl -mno-evex512 will disabl= e > 512bits. > > So scrap -mavx10.1-256 and -mavx10.1-512 please. It sounds to me we would have something like avx512XXX ^ | "independent": TARGET_AVX512VL || TARGET_AVX10_1 will enable 128/256-bit instruction. | avx10.1-256 <----implied---- avx10.1-512 ^ ^ | | | | implied implied | | | | avx10.2-256 <----implied -----avx10.2-512 ^ ^ | | | | implied Implied | | | | avx10.3-256 <---implied-------avx10.3-512 ..... And put every existing and new instruction under those flags > > Richard. > > > Jakub > > --=20 BR, Hongtao