From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-AM0-obe.outbound.protection.outlook.com (mail-am0eur02on2064.outbound.protection.outlook.com [40.107.247.64]) by sourceware.org (Postfix) with ESMTPS id 44DF23856261 for ; Mon, 13 Nov 2023 08:34:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 44DF23856261 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 44DF23856261 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.247.64 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1699864498; cv=pass; b=XQxw9wt12OOgJ3vIkQEUDqOKutMo+UwjPd+sf4YxpOgjy1Ww5yNDA7dnsGYKfNEyZ0qb/FaqH91gc46x/ZsKhyK3a4ONjb2yB5C8D/PZV2yGWxTSxysMx/wuZ7gLqdjYBSJ7iN9zNnOgItcYmtPGqYWnxzW5h5d7aXJKtKx7krc= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1699864498; c=relaxed/simple; bh=IY906UWhHtl1qYoHMrAA3albUSHtJ2XDD7is9QtcZls=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=MQa+LNfqY8S/Et0Rf+3nb97DV7d1hCMhFeN+ZZOProxUv7dYggqt545SMXOvh0jToo51ACCY1MUosooTdBUoiV39yTC/FjJEZQBcPQXrdU8mtUoEoTBrAdyqL6BLJ/K8xTOrLwzbaSn+uCOJjMX9HCekRZbWk4V0J8v0k51OsCw= ARC-Authentication-Results: i=2; server2.sourceware.org ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kCGoEUvIXptCeQVF4hTN/0kPOiqHvQiOnDmHADIE2Ka+s5rtPdiOFE3V7Jl48/VKH9lJN2luVFbsbkp6+DH/Mo+5a7PJBdXlionQHQzLJ7ZthiPQrZ1voJ/RQz5zEVTfGxKaBt8uvEFWVjG0KXKidEZNNYmVwEfcpSu4Si+P9c4df/0cj4hnA3VR1493VbBMuguCVvbAzSUH/5mNsz1nG4aTrjKL1cTSbmOM2P4QTjlp0sbuvPMSc/XQC3BppzR1sUEamNajHTvPd7Ka/evCJ00wUJrN1IPLsf28nqKy4S4NF5U2dj4FDH7valNwRr+VG80/D9WO34PAXqihr1yxnw== 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=pFMovqS0VFHHZzt0ZiOhJTMCUl137C7Ge1YphCmR3Ds=; b=ZUmLddFcVbQkO/NTJRr7QGTCFQaJPUbeJ7NP0HmnnE6m27VYgKcxUxusTEBQeIGuPlaQfUZk5eKhuFMb3AKl38gWXwJT6SjQlqGL27tSk/V1bgY1If00TZ8OL++imLlkwFzC+uFKntS963cOctjguHahKh0b2bU8+CvuemGV/dVTdzlnYT7zP56Oiv7Up2m7klDp41+mFMUp78NAYjnqnmpn+zqvK4MTGEWktVe+CsjvDx7KbkciQwgrRVRKwoDPxeZVYs92qwC+38w3tWs2U6Jzjla0aBln4Ke1XguSFpWNnM5n6K2uyiYbzXx1JI9uj0cg6ytveUthDNEiMuKPew== 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=pFMovqS0VFHHZzt0ZiOhJTMCUl137C7Ge1YphCmR3Ds=; b=bj++IxSN3wXewl8a8joMaqPT2/ehaVPjD3QpILjTq9ThMMJHt+QE4hVnM0QVteBnzwkvo/WF7f/a76VCcpYjg/1Kc8JuaLHd5Aue5FQhBnn36h+0iVXBDijNA5BOjbrpaoWoWlA6sEK9IVhRgAzM1oXJCz7+GlBP40XSfBgK7CMlGSR8ihA3MCI8ZYepmo4f2l0kwQyzvGBPQoc19jNhcycHSBCU6zWx+ef7BRU8w1ILDcDR09yJCpp5Uzv9a+V+jCTj95N6qltfX5bLVjv8LhdzJ0UuihwRZ+FXJSrwX9fSYEOwJMU5q4O/JmaUKw5hFSKweZ5ou5ch9meq8FH9qA== 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 PAWPR04MB10008.eurprd04.prod.outlook.com (2603:10a6:102:38b::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7002.14; Mon, 13 Nov 2023 08:34:53 +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.7002.015; Mon, 13 Nov 2023 08:34:53 +0000 Message-ID: <80453745-239f-29e5-072a-f97fd771738e@suse.com> Date: Mon, 13 Nov 2023 09:34:52 +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: <2bdf64b9-f0fb-4d16-0a82-9edb36fa409f@suse.com> From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR5P281CA0010.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:f2::11) To DU2PR04MB8790.eurprd04.prod.outlook.com (2603:10a6:10:2e1::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU2PR04MB8790:EE_|PAWPR04MB10008:EE_ X-MS-Office365-Filtering-Correlation-Id: 0e367557-5106-4c73-a4a7-08dbe4236890 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: rU6A12E6ArANnuZAxanbmRRsOsJIeg8m9bQ9fx341oFUjzXvj2JHGUy7K1ZZIjPltUsyDyydjg2x2k5GVYgfx6Q1Icj9x8PCdIpaJPME9fOZ+1Mq/0FdWEPuZz+1IWtdlc4puiAjHtU4ttKvNqR3N4AvSk/ipV3HpULT4lCMz5MoSu7R45btpqIF6aFcnvlzfEmr71vRhpfAmzvrSH5tK6FpVU37dofuhIktR78rlrVgpquFoFwalcRezr21nfdmTFCf0G5nN2pue3wblxnXAC8oDoDFpxcNI37ojyDX7nIbNyeWMDe4GWcANtIoF8YmX3oF+0kAy00jJ9mr1sfGgO05udTGLTm+ooMwVmsx0pbceuWt/jSebKPP7qBm4UIP828bSaqAY/aPfbaPBzjUv0g48ucIDzhBxN46u5o/BFrRgWY8zjl8YNjxsj72Z26lSrrq5UPsL3ZaMWMJMCwQkjC/UBpDt4X3Dy58uvea0IVftkCHVNMWW1PyF6HKNlLvtmk+vY1bxVS6+0saP+mp0I2+Sv1QEW8BwmJ57T0IHwseRR7ifAtYMDhs3GFFl44eCIlwn56p4zKZlnDmqRk2DwAs6e3eieBhtm3FM64xrxc0deHiMxy1C4IDj+51Fdu7tIwHj3Keq0TMBfCv4RhYcQ== 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)(39860400002)(396003)(346002)(376002)(366004)(230922051799003)(1800799009)(186009)(64100799003)(451199024)(66899024)(54906003)(66476007)(66556008)(66946007)(316002)(6916009)(478600001)(6486002)(86362001)(5660300002)(31696002)(41300700001)(36756003)(2906002)(4326008)(8676002)(8936002)(26005)(31686004)(2616005)(38100700002)(83380400001)(6512007)(53546011)(6506007)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MFVScnlsd1lJZEpObW9jcHNrRTQrUzZDOE5nRGx4Q1NIVlF2RWpNeWdWV1B6?= =?utf-8?B?KzZQTXJKWXJhVHdVdTVlSmpOK1pDVlNqWmZaYU9sS0RIWXg1VG1aT1dvRmhO?= =?utf-8?B?NGxLK1FOYndBcDlveThmcTBXY3lPbTBqclNSTzcvYVRkbnJVeTMvMXZ6RGNv?= =?utf-8?B?MG5Za282K3MvTHUwQTdkMWhnditIaFR3eU1lUElMMEN4UWZiSURSV21CZ0U3?= =?utf-8?B?emFIcEFRWDNrRmlhSVg1QWRpU0V0dGdJOUxDY0xnU2NFUmlEUUZYU3lxWFVU?= =?utf-8?B?bkExb0RKZkZXdUZsSmFXbXZMa3JnS0VTVTU5d0dJYVdoVmdFSmxqZGJZQ1gr?= =?utf-8?B?eFlPbjJlck1zbjJaSnJIRGNiM3pVWm10V3J6VGhwK25sTm9IU3psZFRwcXd1?= =?utf-8?B?cHRCNVBVQ1JxMFZiVDMyU3FPbmlTNmdPK2N0QzN5em9LZGRwbkt5ME1UMUVT?= =?utf-8?B?NEJhekhKTzZZWHdpTmxINGZaSjBSR0Z2NVR3S0puTlBhWnhmdWZZNTNMdTdu?= =?utf-8?B?ZkhtSWxRVnp3K2lKR1U5aGxMZmcxVDJIaGJYVytMTXBRMGNsTituUUYxZmF6?= =?utf-8?B?ZWl4M0FqRWRrcGlkZHc5cWRaVkhZSlg1Q2c0SEV3Z25ZM3dQYVlWQW1QRXB1?= =?utf-8?B?YjlUenJRbk5yMzc1L29uYk5BamVKN3IvSi9tZUpIcTNHOFNsMWhqWlRmbFpn?= =?utf-8?B?Z3dSbGRJdU0wNHZYVktDeWEycEZsZ1ZYR1pqVDdsWjhxd3g2SnhhdDFka20r?= =?utf-8?B?ZkVpdUlMeFlicUlCUEtOTHJGbys2NlRWM1dKRGkzV3VlN3F3ZVR0Slppa3l1?= =?utf-8?B?S21rWDJVUTZWUkx1WXRGZGhhdy9LS0hEU1RxYjdxSk5oM0huMUcyWm5ORnZm?= =?utf-8?B?TVBjSE80VkFERkczUThqNEFmUGpJYTEvOU5pdklNV2dnYU9mVDd1MVoyWkNJ?= =?utf-8?B?bDhMSnlJV1huYXlPL1FMNkphTGJtZUo5bVZlMENoUEErYlAzcStHUEUyeEdJ?= =?utf-8?B?K2NSN2N3bVpkdVc0Q2pjS2R0U0ozRzkva1Naby9sM0ZnZnNnM2UxaklNMlkw?= =?utf-8?B?cGEra1Fib1hVYzRoM0k2UmFGTDdKRlFFaUpEV0JmN3lQOHl2ZXo1MFRmZ0M3?= =?utf-8?B?SkFaaHFKNytGNTdoZzk1UmNHd0twRzM1Y3FXWlBTL2ZWaTF6ODBmTzlIbi9s?= =?utf-8?B?Q0xIcVpvZWwxaHZ0eVdhNEJONnRua3dZMjhqZ2Njb2l1NEhNT3lNQ3Nlc1gx?= =?utf-8?B?dy9YK2JMUnhPUlR0Z0ZhbG1jR0ZnaEhoeVZ4a1JkQlVZd2dnRmdvTGVRRGJ3?= =?utf-8?B?eFVJSkYva29GaGpqbEZoSk9BM29lUWNnQ1RhSU5aSWFWY3FFUzdGVzgvWWU2?= =?utf-8?B?dE52SVRWS3QwQ3lMZkV0QWc5NzFOaFdmOW8vT2hrWjBRVTZ4OW1MSHlPb1Y0?= =?utf-8?B?WUFOc3FWcEtqdmd1QnlXMlpGYTd2U3gyWFhJUnpoOWZpR3ptRHA2SFIrejB2?= =?utf-8?B?VkxkRVBsaW5FaERNeFhLeFFNWlphMHNXdzdJVlV2RVJ1cUswQVBmcURKenF5?= =?utf-8?B?VUtTSEkrT3BrRDBtWklaNUlyMDBmRGVvSDkxVzdHTUNkK1I4SGw3R1JUd090?= =?utf-8?B?T214bnRZK2dBdnhiMlpWTFVhTW8wL01Cek5Rd2ErbEFRSC9IVTFheDg0eWNn?= =?utf-8?B?aDhwajJkUmtPd3lGL083bUc2ZmNkcGdmVXlSdWJKSnhyMUsxWHZ0cStzdEJV?= =?utf-8?B?QjdIVVQzVXhwRjg3dm04Wk5xS0MyR2VYb3JPMnZnM3J6UTZCVTVjNG1wQzNx?= =?utf-8?B?cXB3cVM1QWtTcDJORk5QS0xscGk4SGhnQXUzNmpScytmN05xWktQMUtDZUdT?= =?utf-8?B?ZXJlVXlkTmxLMm1JTnNMZ1U1YnpJa1NKZ2o0UDg5U2h0RE8wS3dZL3ppQ2NP?= =?utf-8?B?Zk85VEdnMFdxdkdEeXVGVlhQZS82TTNhZkxsOHlML3J2RWk2Y3JLUklZa0dI?= =?utf-8?B?NTNxaGRRempzcjBtMjVYMnlVanU4eGlHc0d5VStJMjRlQ3RiakFjNkJhK2ZZ?= =?utf-8?B?aFhtd1hsL2w5bS9PNzVFWmJtMVRSY2JOSmg5RndOUGxyajA4bTh5T3dTVGtM?= =?utf-8?Q?EDXY58FIXnss0D5eF72bbYdhn?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0e367557-5106-4c73-a4a7-08dbe4236890 X-MS-Exchange-CrossTenant-AuthSource: DU2PR04MB8790.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Nov 2023 08:34:53.3986 (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: DWJPtVGy6yXY2Gme28UOZiONh6YoqoW7Gl0k6RoL44EPfcW1kOm7uIyItksSKCN0jc6i7dq8yNjiWg6RYGgXtw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR04MB10008 X-Spam-Status: No, score=-3028.4 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 13.11.2023 06:53, Cui, Lili wrote: >> Subject: Re: [PATCH V2 3/8] Support APX GPR32 with extend evex prefix >> >> On 03.11.2023 17:50, Cui, Lili wrote: >>> @@ -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 ... >> > > How about "check_if_any_vex_is_evex_apx_encoding ()" ? That still has "any" in the name for an unexplained reason, and the new name is yet longer and hence yet more difficult to follow. My question was rather towards simply dropping the "any" from the name. Unless of course you can clarify what "any" means there. >>> @@ -5624,19 +5653,42 @@ md_assemble (char *line) >>>[...] >>> - 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? > > Added the code as below, I added as_bad instead of assert, I think this is a input error and not a gas internal error, right? Besides REX_PREFIX? > > if (check_if_any_vex_is_evex_apx_encoding ()) > { > if (i.tm.opcode_space == SPACE_EVEXMAP4 && (i.prefix[DATA_PREFIX] != 0)) > { > > i.tm.opcode_modifier.opcodeprefix = PREFIX_0X66; > i.prefix[DATA_PREFIX] = 0; > > /* Prefixes other than the rex prefix cannot be used with the data prefix. */ > const unsigned char *p = i.prefix; > > for (j = 0; j < ARRAY_SIZE (i.prefix); ++j, ++p) > { > if (!*p) > continue; > > switch (j) > { > case DATA_PREFIX: > case REX_PREFIX: > break; > default: > as_bad (_("unexpecting prefix %x together with DATA " > "prefix in front of evex-promoted apx " > "instruction "), *p); > return; > } > } > } > > build_apx_evex_prefix (); > } We already have code refusing most legacy prefixes when ahead of VEX/EVEX, don't we? I'd expect that code to take care of bogus DATA prefixes here as well. Possibly the conversion needs dealing with differently if here we can't tell a user-supplied i.prefix[DATA_PREFIX] from one internally derived from operands which were supplied? E.g. by not having process_suffix() invoke add_prefix() in this particular case at all, but instead modify i.tm accordingly? >>> @@ -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? >> > > After merging vex and evex, evex exits here early and all evex supports egpr. Yet / hence no EVEX template should ever have NoEgpr set. IOW I still don't follow why this change would be needed. >>> @@ -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? >> > > If apx_f is not supported, it will return false, just after this code. Oh, better to move it to the back. Done. > > if (r->reg_flags & RegRex2) > { > if (current_templates->start->opcode_modifier.evex) > i.vec_encoding = vex_encoding_evex; > > if (!cpu_arch_flags.bitfield.cpuapx_f > || flag_code != CODE_64BIT) > return false; > } Hmm, as before there's a use of current_templates here, which I'm afraid isn't appropriate. Whether a register is legitimate to use depends on only the present mode we're assembling in (flag_code + cpu_arch_flags, plus a few other globals for certain special cases). There may not be dependencies on the insn we're processing. Or if at all (yet even that would need a pretty good justification), then only on the collective set of all templates in the chosen template group. Jan