From 4fc85f37dc7ab02867c5f7ee69e65b2f5eba51d8 Mon Sep 17 00:00:00 2001 From: Jan Beulich Date: Thu, 14 Sep 2023 08:43:45 +0200 Subject: x86: support AVX10.1 vector size restrictions Recognize "/" suffixes on both -march=+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(). --- opcodes/i386-gen.c | 1 + 1 file changed, 1 insertion(+) (limited to 'opcodes/i386-gen.c') diff --git a/opcodes/i386-gen.c b/opcodes/i386-gen.c index 8b6eb2e..a3e388a 100644 --- a/opcodes/i386-gen.c +++ b/opcodes/i386-gen.c @@ -464,6 +464,7 @@ static bitfield opcode_modifiers[] = BITFIELD (StaticRounding), BITFIELD (SAE), BITFIELD (Disp8MemShift), + BITFIELD (Vsz), BITFIELD (Optimize), BITFIELD (ATTMnemonic), BITFIELD (ATTSyntax), -- cgit v1.1