From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2048.outbound.protection.outlook.com [40.107.20.48]) by sourceware.org (Postfix) with ESMTPS id 88C723858421 for ; Mon, 6 Nov 2023 17:07:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 88C723858421 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 88C723858421 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.20.48 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1699290440; cv=pass; b=K5MaPE1nYch5gs7oMIIg23xbj5aMc+5W2lL1kKQhNB7doIwnOfQkZ9CwsIEoOdFPqcBlOoKoUIoFWWEoHqupH1N0YUOBU93/crrw891CGaH5pNBSmNQXdWiJqO05Mtfxi57f4veyuMIA65PV1v1HM2RBjaq8dj50NhiJcj/M1Mc= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1699290440; c=relaxed/simple; bh=J3Sn309yd+yYCqEPpNmd/DewuE/7cxhPjlry56jiwbA=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=QHxGpvtjTpOM3cqfncWyJckzIYkKbvvJvEb4x7fs35bTb1P9CEVDJP5vev+DuYbImGjTpqsahLMpdbSPP9RIUNDN2KhZiDXZj8tnbVewgI6kA0hYuKY7sNCKpeRCHmTDlTE33UyxcETTkw4gnsMzLnHI8syiDoMDz0ocjUtOBGc= ARC-Authentication-Results: i=2; server2.sourceware.org ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Hpse1Azm4V8yJlFvAb7xRcBtWDQpE+eN9HnAOZ1as6xZWwE71U5wHbWvFTF7K7+IGDj41EdfHeekrpcpexcHLvrFrE/b+vp4+kpIbiHXxg2sIM11shTAWoBAQuuEfOXUQ5/wEsnmSEqdf2WOZm2JaFdmRZBvheb2PruPu+D+C8i8szq28V0gbUyF4EAroZOeERnBU68bW8+6G0BzMIavdJ9Rqka4rfxmA8J9pk67Ji/AJEhWPM1w+/TjPf8l34OTDK5IPLMtrOvEn6dfbvV8A4KPE3m+6G2L7yXIuMjUuqhQ2+R608P9IYWCGpF+QMmuKf2yadkwwC8yjMQoTwYqYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=H8/xMRGZartWcVOvpcyNd5WKz/ivLPhoQtQc7yJiT18=; b=dTm7hIEi6+QCSva48NL5EJD+GNqOBDSGb3OOoB5/ZLxHHw4nVL+sAoqUWUdekWm6lIAn8j6W/Q+GANQllmGRBu3dgGvb3xBmr1oMOThs+d6JZMAA+8DBnA89ygVJpUvS7EcxBmmlnGTlPgRsbUWMsaFs7OATfTzP49rWTtjSJFf7rQHLob3HVTqeLu08ilmKWpOY1+ns6/Tv8Ssmj2moVKrEqMpXoImc41rEKYbrLdcMXwwlYR5bLy+0X/pnPGzVkd7a1j4aYYyq1v8pvlhUUOvdTlk9gmDcgKfn8DhMlsv+bqWnCEBBPDPMhA379+g89Px0/BiA79hSaIQuhy9LRA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H8/xMRGZartWcVOvpcyNd5WKz/ivLPhoQtQc7yJiT18=; b=jTDpzigOv62KDgJ4Txm/ZcdvSzMxBe84zyOmZJEwdSBiT36dafXWO2H+rUiP3hLGCuRE846osjLkQ0BSs/ei/+Ej2JzCHAY8WxFgqyXUMurOks1WEpK17/nj+pp+YtbuyK+kZ6YZm6lW8jvG3dc97zhwYHL364FCZSgU6fW/hvV9NjqwNroSMg1eppN75/G7qFpU6Prh6wDbecokYsOQeGOsldl+txTzCFWp8W9EeL9JVKwlVHBvGNZXNfLOaX46woIxZZsf+S+/UXbu0Cw9rc66hDrtRVhlM3Fsp/RYvG/UNNeMPlpURCv+aFs0CXWWde3izhsex43gjOLMjiDChA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com; Received: from DU2PR04MB8790.eurprd04.prod.outlook.com (2603:10a6:10:2e1::23) by DBAPR04MB7205.eurprd04.prod.outlook.com (2603:10a6:10:1b3::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6977.16; Mon, 6 Nov 2023 17:07:15 +0000 Received: from DU2PR04MB8790.eurprd04.prod.outlook.com ([fe80::eb8e:fa24:44c1:5d44]) by DU2PR04MB8790.eurprd04.prod.outlook.com ([fe80::eb8e:fa24:44c1:5d44%3]) with mapi id 15.20.6977.016; Mon, 6 Nov 2023 17:07:14 +0000 Message-ID: <2bdf64b9-f0fb-4d16-0a82-9edb36fa409f@suse.com> Date: Mon, 6 Nov 2023 18:07:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH V2 3/8] Support APX GPR32 with extend evex prefix Content-Language: en-US To: "Cui, Lili" Cc: "Lu, Hongjiu" , "binutils@sourceware.org" References: From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR5P281CA0025.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:f1::20) To DU2PR04MB8790.eurprd04.prod.outlook.com (2603:10a6:10:2e1::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU2PR04MB8790:EE_|DBAPR04MB7205:EE_ X-MS-Office365-Filtering-Correlation-Id: 79561992-882f-4724-da39-08dbdeead2ed X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: hDSfJ1CexTqc8W+3oP5NXgJTI8bRTuh8X5vibXvIK/GA+J1Zh94G7d6h0pcQlg2hzdKFDZN8AQK7Z3WO28WB0XiwcRhA+u9V/CBWW/dBx3d2b7i6uF4IuIkZCQIMcR3GDhoI1fEyFuOHv3PXs9yRpFSPftvHAOwnHu5PkJWMa+2SlE8PQvcnuN62ohQN7m2Z2M172ei3Oi1s+VZ2uf1+ywcGYB4+8s9TO6k4PmCBFKMTBQTqA5I5JdCVHJgbTPiY8q4A1lQ6NyRyImh7JtYP4HEEFN5Xz7wjW4SLs9myh8CBtZqEy7CYpZVxH654LVoeByAZG1s7hVFcU7d3RfQeYp4FRytzvYL3wiEdlVb/eBLZUO01U1K387XZL0NrZhY2waidqSQ0+hoPz+RAtcMR+MrRCz49dSZgDiD+8Wv6yR1ZiICq33WR+MnZYmxjB4fkKJfeOx51FncoiBscnjzOeDPQEdPtxxjDOicjup4RxLD2USDnFMC5Br2wkAGbGSxpaeVV0zVVPtEOy2nm7HRq3vRj7x2SUA3hPtycPYAbecU4V8l0+P/oldoB7ndX9eeiyumaFQ04jpBb/jWI6cmbOtF1sQOcTUVzbQDz6W1tGHaq/H3AUZY5XVmjLTqfw++wxffHIUxQMA8SmfvCKNgPBA== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU2PR04MB8790.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(136003)(366004)(39860400002)(346002)(376002)(396003)(230922051799003)(451199024)(186009)(64100799003)(1800799009)(2906002)(41300700001)(4326008)(8676002)(8936002)(86362001)(5660300002)(31696002)(36756003)(31686004)(53546011)(6486002)(6512007)(478600001)(38100700002)(6506007)(83380400001)(66556008)(66476007)(66946007)(26005)(19627235002)(2616005)(6916009)(316002)(54906003)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Vy90MUYwMy9SL2psZ2xBMEFiV2NMOUNLWm1Rc0VZMDFFUjRWQ3hrVHAyLzJ6?= =?utf-8?B?OUdZOUd2OTVVbEVGajJqaWR3Vm9WcWdCS0tOek05N2k0REkyMzdvOWJoQVdS?= =?utf-8?B?b1hGUHRQK252S1l0eWJtdjJlRVgxY3VaOUZYb2xuekZQSWpRcWhISm5xcDg2?= =?utf-8?B?TjdFWXVYLzBPbVplU2lySE4rWGFVMTNYZ3VVQ0VJN2RvOWZOMStPeFhPRHh0?= =?utf-8?B?U3J3dkhyY1lZN3dQQ2xsbWxBR0o4cUE4Z3l3dWFqN0J6YnRORzMvaDcxd3Jh?= =?utf-8?B?cUNVNTBCTFlsWUFWZkFJQkVhNndJMU9LVmJNb2Q1NGVHWWhWRUtRVEVTd2Vy?= =?utf-8?B?ZGJhaFdrYmdjdmdMdjU4RHd3S0xDZ3Q4SUYwQW5zQ2hRQUN2cTM1VXBMWnl5?= =?utf-8?B?ajQ1NUlBTURBSUVZZ1YxcHZDT3o4UHFwODF6UjMxVDBSRUwrTlpSNlAyaWdj?= =?utf-8?B?Z0F2MzNHL2VuLytCc1o0emhTU3NzK1hPejJ0STVsenlpWjVYZHVnWktDY3cy?= =?utf-8?B?RTdWTkZqbG5acGJWUWY2RlpQMU1uenV1b0VmSnFYQnNLUURKaUg3Tnd6U29U?= =?utf-8?B?cFBYWTlQbXJTMmxFbGdUSllHUmswYUJnejl1YW9vQWtOSnh0RnRhS3JmbXo4?= =?utf-8?B?bjVmbngwNW1zb1JtNUhRd2ozMFd2eE1iM1hCRDVUOTl6ckpJTGx6aFBCcDBo?= =?utf-8?B?T1NJWE9nZmVUNGNLRmI3a2pWN25hNTlEek1sWjhFbzAxaEJtN3c4RndoYkpE?= =?utf-8?B?L0M4OE5yMHRaM3c4dThLWklTc1VXNk44TXhEKzExeVdTWDNnOVRoMTdXbmxm?= =?utf-8?B?NGE0ZFY3ODUyVUhJbWhQWndHSklsWkphVkVuTHdLMHhWMlJyMmlDZTlpNjV1?= =?utf-8?B?YVpiMk5IdWhVY29OT3A3dDA5aEQwN1RhVWFqN2MrUnBSdTNoN2ord1N1Wkhv?= =?utf-8?B?OEd6ekZjWm1tbktjc3FxN3NTb2JRdkwvdVJobno0WkYvQUExOEVXWGFtenBL?= =?utf-8?B?VEpzMWYrVjByM1JyUDhkNlpKWndUelIySGM0azJvWkVUL2E3MHBwbXVTYkJQ?= =?utf-8?B?QXM2a0VsdXRtUFdOVlV2NDlGV1haa281MVVjSmw0NFgyZTNFMG1sQWdFcVly?= =?utf-8?B?dE11dERpZjRHVE8yZzYweEpBWkx5RFVSLzBLTGozdTQ1WnZkeTJQbG1DTWpO?= =?utf-8?B?RGdPbm1oL2RvZmVRV1psMWxCYXhiZmVIcGV2V05WL2VSYnNRV0lyOEF6TUJC?= =?utf-8?B?VlFSem9WdUgvQ245N2VGVWR1QzNTL1Q3cGZXNnZpamxJZXRlM0thOWpYTE5l?= =?utf-8?B?UFB2SzdMblZWTjQ0WUR5cllFdEpVbHpZZzZWa3FpRDFsUkpLUEVCOHJmUVF3?= =?utf-8?B?bU5yZkVWLzVLSWlPT05lRW1XU3orNDR6Z2MrQi9FcmViMms5VkRRL05CUGdw?= =?utf-8?B?ZkpwU2I2K1d6c3Y1UlEybEFUSk9uTkZmUmt4T3ozYnp1c055Q3FzK3o3SnFP?= =?utf-8?B?V3Z1ZmNDclorOHRPcENJL0Jjcy9qQlhFM1pKdlRtYXpSbmhBNzhjckFndkJx?= =?utf-8?B?SUJ2SHM2V3lYL3ZSVi9VSlBvNTQ2OU8zc0JiVmVkRkNNQ3ozaEl3ajZyc0E4?= =?utf-8?B?dGZ4Zk9mZ0ZMN25Za0RpbFgrU2Z0aHc0N3IzWnN2dDFyMzRnMUVwUjcrekhU?= =?utf-8?B?TDhVSldkS3NkcE5VMkZnbDlIejZlS2ZlckxUZ0hmSUtWaHVGMmI0VUZqTWhv?= =?utf-8?B?cEgyQWZXT0hENkgrbDJjcUYxYzlyOG9obFlsR1FNd0tMSEdBVUJlNmlSdGlv?= =?utf-8?B?M1JRbE9VSHc2UEh2MzV5Mzdzd1V6WE5iWFdsOHkyanYrRWM2Nlp2STBPNUZv?= =?utf-8?B?ck5XT0lkYnNta1dpUHVRR1c2VTRyOVIrdGhkYTY4TGhvSnpaTmpQaElFM1pN?= =?utf-8?B?U2RyV25SakFqNWM4dSsvR1J3M0l1TDRxWnVwWFJPYzJZUHdveUc5NDlyazlU?= =?utf-8?B?OE55MGhVODRRZTA4VjN1TWVLQm45cm0rdE51QzArNE1sdW5hRzhJSjdZVW5j?= =?utf-8?B?VlZSeFl5eGdvY2l6c0V4SzNJMU5rQ0liMkw4ODNFRkh5YXhXUXVnVS9obGww?= =?utf-8?Q?9j1N3W/0YVeG7uEpggv4DP8tl?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 79561992-882f-4724-da39-08dbdeead2ed X-MS-Exchange-CrossTenant-AuthSource: DU2PR04MB8790.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Nov 2023 17:07:14.6861 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: d1TPsJlMND6u10EhIT+G8GixzZ3HgLccm3JY8rAWit3sr3ark8h6zLN4T+I2JlUyNnELA9RPXzVJD6Pi0SRonw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR04MB7205 X-Spam-Status: No, score=-3028.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 03.11.2023 17:50, Cui, Lili wrote: > --- a/gas/config/tc-i386.c > +++ b/gas/config/tc-i386.c > @@ -3672,9 +3672,10 @@ install_template (const insn_template *t) > /* Dual VEX/EVEX templates need stripping one of the possible variants. */ > if (t->opcode_modifier.vex && t->opcode_modifier.evex) > { > - if ((maybe_cpu (t, CpuAVX) || maybe_cpu (t, CpuAVX2) > - || maybe_cpu (t, CpuFMA)) > - && (maybe_cpu (t, CpuAVX512F) || maybe_cpu (t, CpuAVX512VL))) > + if ((maybe_cpu (t, CpuAVX) || maybe_cpu (t, CpuAVX2) > + || maybe_cpu (t, CpuFMA) || maybe_cpu (t, CpuAMX_TILE)) > + && (maybe_cpu (t, CpuAVX512F) || maybe_cpu (t, CpuAVX512VL) > + || maybe_cpu (t, CpuAPX_F))) Something's odd with formatting (indentation) here. I first thought I had screwed up in my patch, but looking back things appear to be correct there. > @@ -3689,12 +3690,11 @@ install_template (const insn_template *t) > i.tm.cpu.bitfield.cpuavx = 1; > else > { > - gas_assert (!i.tm.cpu.bitfield.isa); > i.tm.cpu.bitfield.isa = i.tm.cpu_any.bitfield.isa; You may not remove the assertion here, or else the assignment could silently overwrite a value. Can you explain why you did the removal? > @@ -3885,6 +3885,14 @@ is_any_vex_encoding (const insn_template *t) > return t->opcode_modifier.vex || is_evex_encoding (t); > } > > +static INLINE bool > +is_any_apx_evex_encoding (void) > +{ > + return i.rex2 || i.tm.opcode_space == SPACE_EVEXMAP4 > + || (i.vex.register_specifier > + && i.vex.register_specifier->reg_flags & RegRex2); > +} The use of i.rex2 here doesn't fit the name; the sole user has first checked that no legacy encoding is going to be used, and that's a prereq here. Such a prereq needs spelling out, such that one can be easily aware when possibly adding another caller. Also, what does "any" stand for in the name here ... > static INLINE bool > is_any_apx_rex2_encoding (void) ... and also the one here? In is_any_vex_encoding() it refers to VEX/XOP/EVEX. > @@ -4161,6 +4169,27 @@ build_rex2_prefix (void) > | (i.rex2 << 4) | i.rex); > } > > +/* Build the EVEX prefix (4-byte) for evex insn > + | 62h | > + | `R`X`B`R' | B'mmm | > + | W | v`v`v`v | `x' | pp | > + | z| L'L | b | `v | aaa | > +*/ > +static void > +build_apx_evex_prefix (void) > +{ > + build_evex_prefix (); > + if (i.rex2 & REX_R) > + i.vex.bytes[1] &= 0xef; I think this would read easier as ~0x10 (similarly below then). I also think ... > + if (i.vex.register_specifier > + && register_number (i.vex.register_specifier) > 0xf) > + i.vex.bytes[3] &= 0xf7; > + if (i.rex2 & REX_B) > + i.vex.bytes[1] |= 0x08; ... it would help if the byte 1 updates were kept together (the compiler may even produce better code then), and maybe ... > + if (i.rex2 & REX_X) > + i.vex.bytes[2] &= 0xfb; ... the byte 2 update ahead of the byte 3 one. Also why do you use register_number() here, and not the RegRex2 flag? > @@ -5624,19 +5653,42 @@ md_assemble (char *line) > } > > /* Check for explicit REX2 prefix. */ > - if (i.rex2 || i.rex2_encoding) > + if (i.rex2_encoding) This change ... > { > as_bad (_("REX2 prefix invalid with `%s'"), insn_name (&i.tm)); ... further invalidates this message. Yet iirc you said you removed the i.rex2 part of the check anyway from patch 1. > return; > } > > - if (i.tm.opcode_modifier.vex) > + if (is_any_apx_evex_encoding ()) > + { > + if (i.tm.opcode_space == SPACE_EVEXMAP4 && (i.prefix[DATA_PREFIX] != 0)) > + { > + i.tm.opcode_modifier.opcodeprefix = PREFIX_0X66; Perhaps better assert that no other embedded prefix was already recorded here? > + i.prefix[DATA_PREFIX] = 0; > + } > + > + build_apx_evex_prefix (); > + > + /* Encode the NDD bit of the instruction promoted from the legacy > + space. */ > + if (i.vex.register_specifier && i.tm.opcode_space == SPACE_EVEXMAP4) > + i.vex.bytes[3] |= 0x10; Why the restriction to map 3? And why is this not part of build_apx_evex_prefix()? > + /* Encode the NF bit of the instruction promoted from legacy and vex > + space. */ > + if (i.has_nf) > + i.vex.bytes[3] |= 0x04; This wants to move to the patch actually introducing NF handling. > @@ -5663,16 +5715,17 @@ md_assemble (char *line) > instruction already has a prefix, we need to convert old > registers to new ones. */ > > - if ((i.types[0].bitfield.class == Reg && i.types[0].bitfield.byte > - && (i.op[0].regs->reg_flags & RegRex64) != 0) > - || (i.types[1].bitfield.class == Reg && i.types[1].bitfield.byte > - && (i.op[1].regs->reg_flags & RegRex64) != 0) > - || (((i.types[0].bitfield.class == Reg && i.types[0].bitfield.byte) > - || (i.types[1].bitfield.class == Reg && i.types[1].bitfield.byte)) > - && (i.rex != 0 || i.rex2 != 0))) > + if (!is_any_vex_encoding (&i.tm) > + && ((i.types[0].bitfield.class == Reg && i.types[0].bitfield.byte > + && (i.op[0].regs->reg_flags & RegRex64) != 0) > + || (i.types[1].bitfield.class == Reg && i.types[1].bitfield.byte > + && (i.op[1].regs->reg_flags & RegRex64) != 0) > + || (((i.types[0].bitfield.class == Reg && i.types[0].bitfield.byte) > + || (i.types[1].bitfield.class == Reg && i.types[1].bitfield.byte)) > + && (i.rex != 0 || i.rex2 != 0)))) I'm a little puzzled by this (hard to read) adjustment: is_any_vex_encoding() basically excludes most new templates added here, yet for those permitting Reg8 you still need to enforce the EVEX-imposed restriction. > @@ -7043,7 +7096,7 @@ VEX_check_encoding (const insn_template *t) > static int > check_EgprOperands (const insn_template *t) > { > - if (t->opcode_modifier.noegpr) > + if (t->opcode_modifier.noegpr && !need_evex_encoding()) > { > for (unsigned int op = 0; op < i.operands; op++) > { What is this change about? > @@ -14252,6 +14306,9 @@ static bool check_register (const reg_entry *r) > > if (r->reg_flags & RegRex2) > { > + if (is_evex_encoding (current_templates->start)) > + i.vec_encoding = vex_encoding_evex; What if the APX template isn't first in the group? > --- a/opcodes/i386-opc.h > +++ b/opcodes/i386-opc.h > @@ -975,6 +975,7 @@ typedef struct insn_template > 1: 0F opcode prefix / space. > 2: 0F38 opcode prefix / space. > 3: 0F3A opcode prefix / space. > + 4: EVEXMAP4 opcode prefix / space. > 5: EVEXMAP5 opcode prefix / space. > 6: EVEXMAP6 opcode prefix / space. > 7: VEXMAP7 opcode prefix / space. > @@ -986,6 +987,7 @@ typedef struct insn_template > #define SPACE_0F 1 > #define SPACE_0F38 2 > #define SPACE_0F3A 3 > +#define SPACE_EVEXMAP4 4 > #define SPACE_EVEXMAP5 5 > #define SPACE_EVEXMAP6 6 > #define SPACE_VEXMAP7 7 Nit: Please can padding here match surrounding code? > --- a/opcodes/i386-opc.tbl > +++ b/opcodes/i386-opc.tbl > @@ -109,6 +109,7 @@ > #define SpaceXOP09 OpcodeSpace=SPACE_XOP09 > #define SpaceXOP0A OpcodeSpace=SPACE_XOP0A > > +#define EVexMap4 OpcodeSpace=SPACE_EVEXMAP4 > #define EVexMap5 OpcodeSpace=SPACE_EVEXMAP5 > #define EVexMap6 OpcodeSpace=SPACE_EVEXMAP6 > > @@ -138,6 +139,8 @@ > #define Vsz256 Vsz=VSZ256 > #define Vsz512 Vsz=VSZ512 > > +#define APX_F_64 APX_F&x64 What's wrong with #define APX_F APX_F&x64 ? Oh, I see - this wouldn't build with the uses in the AMX-TILE insns. Yet as said elsewhere, it may be better if we make the 64-bit-mode- only-ISAs' dependencies (not just for APX) implicit as far as the opcode table goes. > @@ -338,6 +342,7 @@ adc, 0x14, 0, W|No_sSuf, { Imm8|Imm16|Imm32|Imm32S, Acc|Byte|Word|Dword|Qword } > adc, 0x80/2, 0, W|Modrm|No_sSuf|HLEPrefixLock, { Imm8|Imm16|Imm32|Imm32S, Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseIndex } > > neg, 0xf6/3, 0, W|Modrm|No_sSuf|HLEPrefixLock, { Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseIndex } > + > not, 0xf6/2, 0, W|Modrm|No_sSuf|HLEPrefixLock, { Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseIndex } > > aaa, 0x37, No64, NoSuf, {} Nit: In an already overlarge patch it is extremely helpful if any unrelated changed could be omitted. > @@ -1316,13 +1321,16 @@ getsec, 0xf37, SMX, NoSuf, {} > > invept, 0x660f3880, EPT&No64, Modrm|IgnoreSize|NoSuf, { Oword|Unspecified|BaseIndex, Reg32 } > invept, 0x660f3880, EPT&x64, Modrm|NoSuf|NoRex64, { Oword|Unspecified|BaseIndex, Reg64 } > +invept, 0xf3f0, APX_F_64&EPT, Modrm|NoSuf|EVex128|EVexMap4, { Oword|Unspecified|BaseIndex, Reg64 } > invvpid, 0x660f3881, EPT&No64, Modrm|IgnoreSize|NoSuf, { Oword|Unspecified|BaseIndex, Reg32 } > invvpid, 0x660f3881, EPT&x64, Modrm|NoSuf|NoRex64, { Oword|Unspecified|BaseIndex, Reg64 } > +invvpid, 0xf3f1, APX_F_64&EPT, Modrm|NoSuf|EVex128|EVexMap4, { Oword|Unspecified|BaseIndex, Reg64 } > > // INVPCID instruction > > invpcid, 0x660f3882, INVPCID&No64, Modrm|IgnoreSize|NoSuf, { Oword|Unspecified|BaseIndex, Reg32 } > invpcid, 0x660f3882, INVPCID&x64, Modrm|NoSuf|NoRex64, { Oword|Unspecified|BaseIndex, Reg64 } > +invpcid, 0xf3f2, APX_F_64&INVPCID, Modrm|NoSuf|EVex128|EVexMap4, { Oword|Unspecified|BaseIndex, Reg64 } While ordering doesn't matter functionality wise, overall readability imo would end up improved if you had EPT&APX_F and INVPCID&APX_f here (and the likewise elsewhere, albeit it looks in other cases you already have things the other way round). > @@ -3310,6 +3364,7 @@ prefetchit1, 0xf18/6, PREFETCHI&x64, Modrm|Anysize|IgnoreSize|NoSuf, { BaseIndex > // CMPCCXADD instructions. > > cmpxadd, 0x66e, CMPCCXADD&x64, Modrm|Vex|Space0F38|VexVVVV|SwapSources|CheckOperandSize|NoSuf, { Reg32|Reg64, Reg32|Reg64, Dword|Qword|Unspecified|BaseIndex } > +cmpxadd, 0x66e, CMPCCXADD&x64&APX_F_64, Modrm|EVex128|Space0F38|VexVVVV|SwapSources|CheckOperandSize|NoSuf, { Reg32|Reg64, Reg32|Reg64, Dword|Qword|Unspecified|BaseIndex } Nit: Redundant x64. Jan