From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-DBA-obe.outbound.protection.outlook.com (mail-dbaeur03on2055.outbound.protection.outlook.com [40.107.104.55]) by sourceware.org (Postfix) with ESMTPS id 79D733858C2A for ; Wed, 18 Oct 2023 10:50:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 79D733858C2A 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 79D733858C2A Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.104.55 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1697626228; cv=pass; b=T9Cpqduuqj98T8Pn2vZ/HqZ+8ZiuuAAUI4Z/yTDqLqrtigZXNQNSvqrN8n0M2vCmw+Y8lu8lV/sXE7PyB5tDeg9I1zEl3Rn7LFt1nyJEZSijdFPq/m2dXvDOiLBQ4HNw+6pgdr4vXPw3mffGfEJVWHS+QlDQh0Y915Crbu5CSDw= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1697626228; c=relaxed/simple; bh=gSd54uNyTqiCGwC9SzR4koal0GWsABKVwKS1ZzBAdQs=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=HP/0Nd7gXlsuSJTx5+6dSHZZZxhUvB8k++w/0kChsLsF8RIdZP7QYmnC5dRbi82TpaJj6RaOAGLmQWVosy6qF/ErYUDdBQ5YZLu670lSh/av6ySNmS54BCIqcW/VJwHIdSw7zxCsvnEZWuHCRk43peRpL49fg0Q3nUWQm3wa+FU= ARC-Authentication-Results: i=2; server2.sourceware.org ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BnVRWB/Nv/9BQOZ0g4lVaUBjrZzHBcdoqqLM9Xmlpb58+yAOSXGTjYn0Xi5XwuJA6UiWo3NwydtGpsGncV+VG2weI5PbcGB7TPs36St5FI3nyzyRPO/FlxVKYPpMJo12XRUdQvyPOYV2kmpVQIQdXPRXWwFXinUsgjZ+4Efi6z2A0UQWLBzKYMoR/3arT0EdqwUJQE69FBUKhxJOJrH5GWpSfMwmItT44MioJvOhWJG6c07Ka8WLy8qDdQhlRSqgpydCVxu+rIPxBbfOKKJvwqLNHfZ4K0cyshlVj8lvQxmZfqMSXqcvBNwEJhm1jtS3vL53vSBasZqs2II5HcXmAg== 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=/qzDGeqkLzN2eZwiSmaBTuBZd0zCjw449dh3DoVaOqM=; b=lwuSfFK0SFdxG7xn+VOWJcfo79vbvJXA+hogiiXdfbYzlr9YOvAj4+7XVyebvZTp7fO6g7lHFQ71wMctqTTe+08cJ2wDmRKbp+plzPUbwH2UE5/1CQoI5dy9f4/SUAQFWVux0pm3ic3DMSErz+jH0GBwoHRjtLAKl85GAY1+KfC1gu8GH78ehV+2wFlF58/UMjE5F71v1j7tuNQ0w3BxFeXISCQDU+d9ZS+CFWfCPrud9oPgyVvoAJZyfF9Ssm0z5iygHKjwkeRUOTI85zdbPG6oztRxYT81gOjW9wLGKgf3JIk1kgiZ71oeHxzWpN/AArueRRYMoe6dIVS5FS7sQA== 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=/qzDGeqkLzN2eZwiSmaBTuBZd0zCjw449dh3DoVaOqM=; b=0EjvdhhXEUkqxlhcD6kL9YxJKH4+nmkpC8VS6J+QvIiMHeA8+g2hsGYklXlUu7GJ0yQSIhpRN6f9rd8AuqRRzGlp2MeIkcDzXUAjJEspkUI8w5srHuQZGlD+2OMZZSzrpNVwvz/1+pzzrmL+jeMaGcb48A+6CQzntxds/rUrJ9xiUtcAxnxxELYmSL4IlcE2yFsUJDPgynnznxPo8frmRlC80mF+FxjDP3MT4wJQSHQ8+/Pb9+TZUE62AVy3/tkDGSIo+AX7jQGp4FgqHS1L0+Xqv5bS/+gYwUydgQ7mJfQiWHL/m3CHPZswosWgy3uWX2o6TINyDTohOIEkGvCyQw== 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 DB9PR04MB9961.eurprd04.prod.outlook.com (2603:10a6:10:4ee::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6886.35; Wed, 18 Oct 2023 10:50:24 +0000 Received: from DU2PR04MB8790.eurprd04.prod.outlook.com ([fe80::d9c0:d907:4d2d:15b3]) by DU2PR04MB8790.eurprd04.prod.outlook.com ([fe80::d9c0:d907:4d2d:15b3%7]) with mapi id 15.20.6907.022; Wed, 18 Oct 2023 10:50:24 +0000 Message-ID: <5018074a-201d-65f9-5049-3206e6adf530@suse.com> Date: Wed, 18 Oct 2023 12:50:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH 2/8] Support APX GPR32 with extend evex prefix Content-Language: en-US To: "Cui, Lili" Cc: "Lu, Hongjiu" , "binutils@sourceware.org" References: <20230919152527.497773-1-lili.cui@intel.com> <20230919152527.497773-3-lili.cui@intel.com> From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: FR4P281CA0105.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:cb::18) To DU2PR04MB8790.eurprd04.prod.outlook.com (2603:10a6:10:2e1::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU2PR04MB8790:EE_|DB9PR04MB9961:EE_ X-MS-Office365-Filtering-Correlation-Id: 5de05d07-c166-479a-c211-08dbcfc8082e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: A3GBlyp2USQr90sT99w+9PBLBroh+bVcO6D7x/2CsGEoNxzB1G6Tn5FLnkfzZx1odsLQPuVBCJO2uGCc3n1XjTyQv1r7HUtcJ6Y8nTBWaD/K7s8BF6An/vjuvk6IO+y3lFLvIJLu5qH8zhKhZ/sjG9Oq9bz6XaFiSn6+1i5jCFHiZvoDXOKwKhSdFD2dXzv22v7DU3mdGc0tJnBapcAgEMLT9S9whfvYNzCrbCf67JjZ9YgomkzedgKzFvW2jaREsqRgBoadxEc0VtRjv8iZB5MY/yDQL8hChtFPhuwI5TaUR6nGWXGy6KSlqZRo26IZDDpr9o4R5tsACZiXKQvs2GSz+PuZ1SdHCUAmQljmT18jCzMWQ+B3ti0HVkh1R+c7kTVJwOtJOEy+hcQQXRi5zZw6wZsCSpRJxFYQYzYS4AKAGd/fNvTLbIWIaFzYSZPpy3pybC6w7emxi5QDJQUmu7bIL0DvvCrA3t/J+meZbtW1lRCZt6DtOjG2NOsb9WhD3n1+AVd6jbiENwmpNvOiObd3Zt9FoG/2Zlr0vMVdP/6JGe1/28ewM4cb+zflPnYMQUMfcKa3V8M1vVxbvAXSPgzKy7Ec/g3Wuu0Xga0nUyxYYVxtdq0RWAzLrkJMhSp1WzabY6LA9Bf19oRm/F5mtQ== 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)(366004)(376002)(39860400002)(346002)(136003)(396003)(230922051799003)(451199024)(64100799003)(1800799009)(186009)(31686004)(53546011)(6486002)(36756003)(6666004)(38100700002)(83380400001)(6506007)(66476007)(2906002)(54906003)(66556008)(66946007)(6916009)(478600001)(31696002)(316002)(2616005)(26005)(86362001)(8936002)(41300700001)(6512007)(5660300002)(4326008)(8676002)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NEJ4c2ljZnpWclpvbUxmeGdxK2E5b25kL1Q0K2VoeFZwVmpyamxlV0ZRcUlI?= =?utf-8?B?YXIzODY5RStBOVJRWm5KYUZzVi9HeE8yR3ZBM244MTJMSU9BZ0FYYnI4OWk2?= =?utf-8?B?U1hjY282TkhsVm5GN1RvYm0wSXdZK3pERkZaSkJNZnNGSmlxcWwreUM3bFYr?= =?utf-8?B?enBsbjdGeHArQkMvZ3VUTHlJYTVFTzRnWFZxRVc3Z1dQd2x4ZGRFMUY1anZK?= =?utf-8?B?MTNqcmVleHF6WFk2alErdEl1ZzFlMDE4NlhWN0tkMnBFS3FjdFZ3QUl0VlpS?= =?utf-8?B?WFBPOHIvZC9VWG5EQng0dTNFRzRlL1VIWDFQUlRRWU43WFlsc0o0YkhQeGlQ?= =?utf-8?B?TlRpSDJ3SkpqL0pKRWFJUHhpMnBVNlkzbzkxaTJ2dStjbDZWZXVVMWR6WkNw?= =?utf-8?B?WkVLZ2R2bTVZODlLajVoTXFsOVZRUWRrRDdlcG5FMFhjMTRoRk5lWFREMStZ?= =?utf-8?B?UDl1RmdQbWlvWVIwMXcrR1NVWDgxS29UbDQ0WjNycytuRUFnUm5zQ0haMGFL?= =?utf-8?B?ekZ2aVlOMk9CMi9nMDJOZThIcmFaNUROaE5HU29jV1FiaWZQa2lxUUxGVzBL?= =?utf-8?B?Zlc4MW8rSlJEWExkT0hoaUgxQ2RleWFWaXRkT01FUEE0WjFtdGp5TjY4cjI2?= =?utf-8?B?K1FVYUtXSFg5TVFRMGRNbHNxeUhET2U5ZmRONGlHdXVhN29xM3BjRG1uRmVP?= =?utf-8?B?VkV1ZDQ4OU5QVXdyUWFiUGsrNkNmUUM1OVBnUkt5TVdOWkh6WHp6WStxVWZG?= =?utf-8?B?UkM1ZHF1ck5uZUhhNG10WTZITmZRYldnSm9OWVREcXhKelpWcWlvdWlPbG9j?= =?utf-8?B?TmdJVkpHRTFxZ3B2MEp6UW1sKy9TczBnNHlRemorYldUZmxhN0hJdjBObXFr?= =?utf-8?B?N0RXQ1BXSjhWWkIxVldJdzlnRzZOaXRKNzFmSjgxQWxERENwM1NtUGdYR1Z3?= =?utf-8?B?ZUJqUm1ENVB1RUVzWW5vNkZPN1loYk80YUl3TW16TzBwWmlyaFRNSTBkQWds?= =?utf-8?B?L1hxYUpyM0V4SUo3VVlMK0s5ODV2VnZLQkVrSlFkbXBaYWw3VzhRSUJIbTY1?= =?utf-8?B?cVJzSXppd3Iwb0VSdU81eTJ4MTR6QkxvMXZ1eDJJbHQ2Q1ZEbjFaaGhCcmQ2?= =?utf-8?B?aVdRUlZUSXQzRzNCeWVtc0FoaFQrUEorOXhvR0RHcDRuajI4dW5DaU9CMmRu?= =?utf-8?B?WU1NSWlJOUo4eGtjWkNUZHkyelRQcCtzdTJKU1FKSHZIMmUxbm9vZE43L255?= =?utf-8?B?WUc3R2lxcEc1cFNWNGR2c3lWRHJ4Wm5JNU1FREZTdXZTbzFZakoyY1BkbVZV?= =?utf-8?B?VmhhQXZJWmhXTzNrQ2xrYVVldW9uMERES1Zsam1tV3ZBVWlkbEw1bzhETUxP?= =?utf-8?B?WU9FV0pHUmFyY1Z1THdVRm5oU0drU2tZVzl4VmtxWXVVMzlWWVFrWFdHTjlw?= =?utf-8?B?MklQUGdQM2RGTXlmNnJSQ1NVUGc4YUpIa1JLS294R0FzMlFaWmRyNE1pMjY1?= =?utf-8?B?MFo2YzNUZjdScTROOWhDSTVNK1lGS2dYWTFWUDNqbkw0M3A0ejhTV21YeUZy?= =?utf-8?B?aDNJVnlLTU9RUCs4K2FUZTlESTNPTkdEbGZzSGFjdHZFOHNObjRCVXlHVFo4?= =?utf-8?B?dkZQVzVXd2kzUnhoYkVKbVBIVjRRTkRWZGU4RCtIak9Sbk5NSUVIRjljTWk3?= =?utf-8?B?SWcwK0dveHdTMzZOWGJ1TkluQ253V1dFWlNRK0hDanUzS0pBdVZzWFA1SGNK?= =?utf-8?B?ditIM1ZvMjNnSWs4NzJsUURkNUlSMGVtdHpPZVN6UlBDQndiMWVhajVLWmNv?= =?utf-8?B?RkNhYlEvc2FYTHl0YUMxWHdQK0lzUzBGT1R3OFJXRXllRWRDeWdCb2RGZGNG?= =?utf-8?B?YmRQTmpSTVA2RGZ2aU1XcGFaMzVDSkNqSXMzWlJyQ084WVVMM0RBN3g5TkQ1?= =?utf-8?B?Vk9EdkVTMENnZGJ4QURWRndacEZJL2RvVHpXcmQyMnVsNUFBOVMwTUt0a3p2?= =?utf-8?B?WnhRTUptOHZTYW4zNElmNXdSMmFDa2pOZnhnRWh6NU9CUmJHeVEvL01sMFcx?= =?utf-8?B?V3M4WExnVWlqMjd1RTJxbHBvU2FEMWxwbHRvZzBucXd5VzJjWWVUSE1NVHl6?= =?utf-8?Q?vgk4pESyMMl7yqGgATsDrSR+T?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5de05d07-c166-479a-c211-08dbcfc8082e X-MS-Exchange-CrossTenant-AuthSource: DU2PR04MB8790.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Oct 2023 10:50:24.2059 (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: mxNv7CieiOoaLiOjuCMICLdpj529KO0gNhll4q+scaYCxqTaV1SLQ32XHCBsYfL4/rxaJ6YyHED5ssjVkDTwIw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR04MB9961 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_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 18.10.2023 12:44, Cui, Lili wrote: >> Without seeing how this is used I can't comment on it. It feels though as if you >> may not have fully understood my earlier reply: Even prior to APX we already >> have cases where one CPU specifier in the opcode table using | means "both" >> and another means "either". I think we want to split that, and thus simplify >> the logic in cpu_flags_match(). That's separate prereq work, of course. >> >> Thing is that prior to 734dfd1cc966 this would have been prohibitively >> expensive in terms of table size growth. But now we can afford having two >> i386_cpu_attr fields, one meaning "all of these", the other meaning "any of >> these". To limit churn in the opcode table, I'd be inclined to continue to >> express CPU requirements in a single field there, using e.g. >> (CpuA|CpuB)&CpuC&CpuD (Cpu prefixes re-added here for clarity, even if >> they aren't present in the opcode table anymore). >> >> I'd be happy to do that prereq work (if we can agree on the approach), but it >> may mean a little bit of delay, as after my vacation I need to catch up with a >> few other thinghs first. >> > > It would be great if you could do this (agree with the approach), it is not hurry, it may take a long time to commit the APX to the master. > >>>>> + if (i.prefix[DATA_PREFIX] != 0) >>> >>>>> + { >>> >>>>> + i.tm.opcode_modifier.opcodeprefix = PREFIX_0X66; >>> >>>>> + i.prefix[DATA_PREFIX] = 0; >>> >>>>> + } >>> >>>> >>> >>>> While this looks to be correct for the case when the prefix was >>>> derived from an >>> >>>> insn template and the use of 16-bit operands, I don't think it is >>>> uniformly >>> >>>> correct when "data16" was used as a prefix explicitly. In such a case >>>> either >>> >>>> REX2 encoding needs to be used, or an error needs emitting. >>> >>>> >>> >>>> You may further want to assert that i.tm.opcode_modifier.opcodeprefix >>>> is still >>> >>>> zero ahead of the assignment. >>> >>>> >>> >>> >>> >>> For REX2 encoding, we add no special handling, just follow REX. >>> >>> For EVEX-promoted encoding, such as “data16 >> aand %r25d,0x123(%r31,%rax,4)”, the following existing code will report an >> error. >>> >>> >>> >>> if (is_any_vex_encoding (&i.tm) >>> >>> || i.tm.operand_types[i.imm_operands].bitfield.class >= RegMMX >>> >>> || i.tm.operand_types[i.imm_operands + 1].bitfield.class >= >>> RegMMX) >>> >>> { >>> >>> /* Check for data size prefix on VEX/XOP/EVEX encoded and SIMD >>> insns. */ >>> >>> if (i.prefix[DATA_PREFIX]) >>> >>> { >>> >>> as_bad (_("data size prefix invalid with `%s'"), insn_name >>> (&i.tm)); >>> >>> return; >>> >>> } >> >> Thinking of it, I may need to revise my earlier comment some: RAO-INT insns >> are a bad example here, since despite being legacy-encoded they don't permit >> a data16 prefix to specify 16-bit operand size. Consider the same for e.g. >> AND. The legacy form permits use of data16 (leaving aside that it's better / >> clearer to simply use 16-bit register names), so the promoted forms likely >> ought to permit such as well. IOW perhaps the code you have is correct, but >> the check you quote may need adjusting. >> > > I listed 5 instructions to check the data16 prefix, is the last one what you want? > > $ cat add.s > > and %ebx, %eax > data16 and %ebx, %eax > and %ebx, %r16d > data16 and %ebx, %r16d > {evex} data16 and %ebx, %r16d > > $ objdump -dw and.o > > 0: 21 d8 and %ebx,%eax > 2: 66 21 d8 and %bx,%ax > 5: d5 10 21 d8 and %ebx,%r16d > 9: 66 d5 10 21 d8 and %bx,%r16w > Error: data size prefix invalid with `and' Kind of. I was really thinking of e.g. data16 and %ebx, %ecx, %edx but yes, forms with {evex} would be similarly affected. Jan