From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135]) by sourceware.org (Postfix) with ESMTPS id 871263858C53 for ; Tue, 29 Aug 2023 16:27:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 871263858C53 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-yw1-x1135.google.com with SMTP id 00721157ae682-5922b96c5fcso52607887b3.0 for ; Tue, 29 Aug 2023 09:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693326420; x=1693931220; 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=G1e6PclJ6BFgMxivlIpfCRCUspxjdqBXR2P+xFqS+fc=; b=sUAosVQ95GW6wfmSQZvpwcTyJSBG5F/vHQqfqFQo1ZQkN1B10zsju95aA9xqv6TA+0 cLxFhgMtF1t/e4w2iBihZgRzCTJti+8EK6G+dUAteXJCRrXSN3jTMEGlfo7V50HYboaJ G9N9d+jRsmxWWmhq8SYDK20W5mh341T5k630k4NNyXMuT+FDq0Oov4+9vSngJfJqZFGf 5vDj6CaKLFxXfD4Sjmxuat+wPsZSGLwqlcYcb0gEwiEt1F/iTNNoxE6Mhzc5TUpnFI7k oJP4CHS7sy+9EIH4eytyl61Uscz+gTtp1Zs7Y7uvDEAlUAYv1YLrW8zf9EZWZ9j25RbS c+nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693326420; x=1693931220; 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=G1e6PclJ6BFgMxivlIpfCRCUspxjdqBXR2P+xFqS+fc=; b=I4KD5/BCB20Tk2TxOGn+12x432hgspImZdsXjWLScx3IbdLYySbOvV9BDBfyviSgKb qHRnF9cIpI0+dy7/J1igDw0l7IzpRqP257hZdGCqLkociz5bFGxefm+jJscVUh3r80ZL P2ICWqtD/7AiYgVwku+m83lmo6w5M1VoqdDeXIUMSzf0bgUV5U/2ErCOPfJbCtguP8s3 SOFEvTC1RSTgBxoWOika3TP7CopqJlkkPVMOMeyeC9gHi9Z/AID+g3TFPI3AeumascuZ 2E1z+v7A8jvOnokEKEx9SoJhUEfGz2EzojymwKAohRGn+6dGoU8LBVKamJBwbBovdpKG NLfw== X-Gm-Message-State: AOJu0YwpubusDvOtdTeSsPJbq6lTi5XLcfIBskxbRRfJKX30QRpCAfPQ +xpw1SzYzUHr+NVaZLPA6JXuiVC0o50AVONw3CH4cDLwKUs= X-Google-Smtp-Source: AGHT+IHoTMdVnJktpunAwXRpy9RVUj2t+kpazd3QEJZsPRmeMPzJ6vxdl/hgXkeCBVVo0HBsKehMmWPSkKS7R12me5M= X-Received: by 2002:a0d:db46:0:b0:58d:7ec3:16c4 with SMTP id d67-20020a0ddb46000000b0058d7ec316c4mr33097331ywe.34.1693326419803; Tue, 29 Aug 2023 09:26:59 -0700 (PDT) MIME-Version: 1.0 References: <6f819651-36c0-1c69-8224-fe21f0f96a3f@suse.com> <990c83c3-0776-efdd-e162-5c367f4ebdc2@suse.com> In-Reply-To: <990c83c3-0776-efdd-e162-5c367f4ebdc2@suse.com> From: "H.J. Lu" Date: Tue, 29 Aug 2023 09:26:23 -0700 Message-ID: Subject: Re: [PATCH 5/5] x86: support AVX10.1 vector size restrictions To: Jan Beulich Cc: Binutils , "Jiang, Haochen" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3016.1 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 Fri, Aug 25, 2023 at 5:48=E2=80=AFAM Jan Beulich wro= te: > > Recognize "/" suffixes on both -march=3D+avx10.1 and the > corresponding .arch directive, setting an upper bound on the vector size > that insns may use. Such a restriction can be reset by setting a new base > architecture, by using a suffix-less form, by disabling AVX10, or by > enabling any other VEX/EVEX-based vector extension. > > While for most insns we can suppress their use with too wide operands > via registers becoming unavailable (or in Intel syntax memory operand > size specifiers not being recognized), mask register insns have to have > their minimum required vector size specified in a new attribute. (Of > course this new attribute could also be used on other insns.) > > Note that .insn continues to be permitted to emit EVEX{512,256} (and > VEX256 ones) encodings regardless of vector size restrictions in place. > Of course these can't be expressed using zmm (or ymm) operands then, > but need using the EVEX.512.* forms (broadcast forms may be usable right > now, but this may go away so shouldn't be relied upon). This is why no > assertions should be added to build_{e,}vex_prefix(). > --- > It is unclear whether Vsz is a good name for the new attribute: The spec > leaves open how 256-bit embedded rounding is going to be expressed. Yet > that may require some similar attribute ... > > --- a/gas/NEWS > +++ b/gas/NEWS > @@ -1,5 +1,7 @@ > -*- text -*- > > +* Add support for Intel AVX10.1. > + > * Add support for Intel PBNDKB instructions. > > * Add support for Intel SM4 instructions. > --- a/gas/doc/c-i386.texi > +++ b/gas/doc/c-i386.texi > @@ -213,6 +213,9 @@ accept various extension mnemonics. For > @code{sm4}, > @code{pbndkb}, > @code{avx10.1}, > +@code{avx10.1/512}, > +@code{avx10.1/256}, > +@code{avx10.1/128}, > @code{amx_int8}, > @code{amx_bf16}, > @code{amx_fp16}, > @@ -267,7 +270,11 @@ accept various extension mnemonics. For > @code{svme} and > @code{padlock}. > Note that these extension mnemonics can be prefixed with @code{no} to re= voke > -the respective (and any dependent) functionality. > +the respective (and any dependent) functionality. Note further that the > +suffixes permitted on @code{-march=3Davx10.} enforce a vector length > +restriction, i.e. despite these otherwise being "enabling" options, usin= g > +these suffixes will disable all insns with wider vector or mask register > +operands. > > When the @code{.arch} directive is used with @option{-march}, the > @code{.arch} directive will take precedent. > @@ -1673,6 +1680,12 @@ an unconditional jump to the target. > > Note that the sub-architecture specifiers (starting with a dot) can be p= refixed > with @code{no} to revoke the respective (and any dependent) functionalit= y. > +Note further that @samp{.avx10.} can be suffixed with a vector length > +restriction (@samp{/256} or @samp{/128}, with @samp{/512} simply restori= ng the > +default). Despite these otherwise being "enabling" specifiers, using th= ese > +suffixes will disable all insns with wider vector or mask register opera= nds. > +On SVR4-derived platforms, the separator character @samp{/} can be repla= ced by > +@samp{:}. > > Following the CPU architecture (but not a sub-architecture, which are th= ose > starting with a dot), you may specify @samp{jumps} or @samp{nojumps} to Although CPUID bits in AVX10 spec may leave an impression that 128-bit, 256-bit and 512-bit vectors may be enabled independently. But it also says A =E2=80=9Cconverged=E2=80=9D version of Intel AVX10 with maximum vector le= ngths of 256 bits and 32-bit opmask registers will be supported across all Intel process= ors, while 512-bit vector registers and 64-bit opmasks will continue to be suppo= rted on some P-core processors. Adding avx10.1/128 isn't necessary. --=20 H.J.