public inbox for
 help / color / mirror / Atom feed
From: Jan Beulich <>
To: "Jiang, Haochen" <>,
	"H.J. Lu" <>
Cc: Binutils <>
Subject: Re: [PATCH 5/5] x86: support AVX10.1 vector size restrictions
Date: Thu, 31 Aug 2023 09:18:08 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 31.08.2023 07:56, Jiang, Haochen wrote:
>>>>> I agree it isn't necessary, but as expressed before I view it as desirable.
>>>>> Apart from the sentence you quoted the spec later also says "There are
>>>>> currently no plans to support an Intel AVX10/128 implementation." For my
>>>>> choice of also supporting the 128-bit restriction I'd like to put emphasis
>>>>> on "currently". I think I said before that emulation environments (qemu,
>>>>> sde to name just two well-known examples) are free to implement such
>>>>> further restricted ISAs without then becoming out-of-spec.
>>>>> Plus supporting this mode right away has made me make certain adjustments
>>>>> in what I'd call more clean a way, which I view as desirable as well.
>>>> Since AVX10 spec doesn't specify if mask registers should be limited to
>>>> 16 bits for AVX10/128, doing it in assembler is premature.
>>> It's hard to see why they would remain wider. The more that they were 16
>>> bits only in AVX512F.
>>> Plus of course nobody needs to use the options to enforce the 128-bit
>>> limit. The way I've coded it, it matches what the specification says.
>> AVX10 spec only has
>> Quadword opmask instructions will only be supported on processors
>> supporting vector lengths of 512 bits.
>> It doesn't say anything about 32-bit mask.   32-bit mask can be useful
>> even with 16 byte vector.

How's that any different for 64-bit mask with 32-byte vector?

> The concern form my side is if there is an extreme case that overloads
> registers, we might need to spill 32-bit register to 32-bit mask register
> in the compiler.

How's that any different for spilling of 64-bit registers?

> Another minor concern is if there is finally a AVX10/128, although I do
> not see that could happen, if we get a wrong choice here, it will take
> some more time to correct the final assembler on the user side, which
> I mean on the real OS.
> However, I suppose both ok for me whether to allow 32-bit mask since
> AVX10/128 is nowhere near in the future and it is a toy code to play with.
> We could be some kind of conservative at first by just allowing 16-bit
> mask register. Also, the code change is quite easy and no much worry on
> changing that.

Exactly: I'd rather be overly restrictive initially (which people can
easily work around by using .arch suitably around individual insns)
rather than being too permissive and then failing to flag mistakes.


  reply	other threads:[~2023-08-31  7:18 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-25 12:43 [PATCH 0/5] x86: AVX10.1 (alternative attempt) Jan Beulich
2023-08-25 12:44 ` [PATCH 1/5] x86: correct source used for two non-AVX512 VEXWIG tests Jan Beulich
2023-08-25 12:45 ` [PATCH 2/5] x86: rename CpuPCLMUL Jan Beulich
2023-08-25 12:46 ` [PATCH 3/5] x86: support AVX10.1/512 Jan Beulich
2023-08-28  2:34   ` Jiang, Haochen
2023-08-28  6:45     ` Jan Beulich
2023-08-28  6:59       ` Jiang, Haochen
2023-08-28  7:09         ` Jan Beulich
2023-08-29 16:18           ` H.J. Lu
2023-08-30  1:10             ` Jiang, Haochen
2023-08-30  7:47               ` Jan Beulich
2023-08-30 15:28                 ` H.J. Lu
2023-09-01  8:41                   ` Jan Beulich
2023-09-01  8:52                     ` Jiang, Haochen
2023-09-01  9:57                       ` Jan Beulich
2023-09-05  7:04                         ` Jiang, Haochen
2023-09-05  7:25                           ` Jan Beulich
2023-08-25 12:47 ` [PATCH 4/5] x86: unindent most of set_cpu_arch() Jan Beulich
2023-08-25 12:47 ` [PATCH 5/5] x86: support AVX10.1 vector size restrictions Jan Beulich
2023-08-29 16:26   ` H.J. Lu
2023-08-30  7:57     ` Jan Beulich
2023-08-30 15:25       ` H.J. Lu
2023-08-30 16:16         ` Jan Beulich
2023-08-30 18:00           ` H.J. Lu
2023-08-31  5:56             ` Jiang, Haochen
2023-08-31  7:18               ` Jan Beulich [this message]
2023-09-01  6:21                 ` Jiang, Haochen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).