From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2076.outbound.protection.outlook.com [40.107.22.76]) by sourceware.org (Postfix) with ESMTPS id 6789B3858D35 for ; Wed, 29 Nov 2023 08:30:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6789B3858D35 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 6789B3858D35 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.22.76 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1701246605; cv=pass; b=trDfIIkNkVu/ut6kI63JjmgZA+wDBkfdoD1BVdLBUIsjhLKLIhoq0r4k4k1C8K9ypdfmjMgCfyREisEe/y+sBf2dCo0AzbSkAXuh+OqcOq7LKROHuhOQRu1Avs+5m1TkWKlHk6fr3WEp4EalfiuUyNDgAbMuAdKaUzSYd6Kt+Xc= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1701246605; c=relaxed/simple; bh=QQxtDuYbmR7/PrlyPJ+Buk1B1wBxIl/cYa6Mnc5hiFA=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=HrZES53vFyjxD5a0pDyHY5Ja01vp59A3yW/y+tnPoqG7+lhPEOikVfWfGyQ4IAB4xlU/7STL+cOR8RjwiVIleDhZUYjKkaL2SFDOdrtQkj4vNfhGxDgW/0X7BqL+OxeOpxLdsQNc0MiPqE/cmAKvzFg0fUO34Waso3o9wm58d80= ARC-Authentication-Results: i=2; server2.sourceware.org ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JMOhwTOCNCtQPSsHIIN/HzKVCGhTFT9GPloH49NRhm+wAZAVPJBq4yVAqRDmhgJY/uMmEtxYm82wLj9jFkgzBj3ATt+fIuTVnciaawQlRVxC9DcihfF2DpbHU5I/2Y8O059iNiDChMgfdvnlqMzkot9fymmrfHxlWVE8HVerCXDHEEIMzhKEAGyGQepZvHgdH3NPu7ChQsXYWbzpVcoyAAx8z9omZwDymEhGzLXasSZTopBL8NXHlFmBT8TDr6OHtRl9HVY7uAIHAvPHILGUwu4wr0p3NeTss4kjDIB2dqZCyClgxc3TiBXY0GMfUZ6pTPYsV2S3gSEQ21Kxly/+JQ== 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=2ovu3vSnNLlt+xVNObOjeJldaTGKK2wx6e9fL5Bmu+k=; b=Q5Tbo86Y6rdnd2cq60ZdF8D0rkrsC1cqq2WeFeYpo2IBCnv0eubxLUrCwVn7iifZEjTRhaT5iziVf7N2Gf5FVTE9wiN0KpGoZTc3Z37k1q8zC5xnScXHEs87LZH636bomwSV0pJRMu6C/vwi+w82RsLwNjlWE1TJON92GnsCwQ97wBX5Ylg9WVdVnNzYyUhjSujBUyHu17HpD7xEkdBhwvsMkSpv4S0PuQTIsKeam+JNGCOEf7iX5J/Z3hB7dX6u7mGbwQWB2QKn1M4QPryJhgYGF3SF8RlnJKWHWwT7LsHrf/iTNPulSxjYFTKRZkpTDMfyIjPd0W2/UmSf+qLX+w== 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=2ovu3vSnNLlt+xVNObOjeJldaTGKK2wx6e9fL5Bmu+k=; b=cW5zEyQqCW7Rh7EVUYjd1C00ObW/FRzko6EKsOOAwXzY2fy4NZgXoNzivLLzBnZMZ5gVFmD7Q/wbKdgkRPZseZEkS1K4AAA0fOipLxsGhyhgOcOL81OQ+C2D+NMOHLZku/306AohnhH7DbnQG/08gzKQ9ljnitaHRuLq7AymRav9iMjMd8G2bCiS9Ef8OE8w97z1UR4sdhCePpCzdAeR1rrWPS3VV/xZCj0UJJGovnI9z6sONin8EJ6hdjFo/60jsNugHaKNESvmqt8YpleF4RGJo7H99gIr350h/G2VWery4SSo/5o+rslipmYNgh6ZI1hbf+C/wng2yvWeM1Fprg== 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 PAXPR04MB8476.eurprd04.prod.outlook.com (2603:10a6:102:1df::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7046.22; Wed, 29 Nov 2023 08:29:58 +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.7046.015; Wed, 29 Nov 2023 08:29:58 +0000 Message-ID: Date: Wed, 29 Nov 2023 09:29:56 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Support APX PUSHP/POPP Content-Language: en-US To: "Cui, Lili" Cc: "Lu, Hongjiu" , "ccoutant@gmail.com" , "binutils@sourceware.org" References: <20231127123106.3600817-1-lili.cui@intel.com> <4f005f5c-52c4-4631-bee7-6396add7c5df@suse.com> <3abc4b98-59ab-48b4-8690-99d00e55ad1f@suse.com> <8858e7c5-97b2-4ec4-bd21-6371f92493bb@suse.com> <83c937ed-48e4-4f38-96ec-aab662ae97ac@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR4P281CA0185.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:ca::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_|PAXPR04MB8476:EE_ X-MS-Office365-Filtering-Correlation-Id: 264f3a07-1a35-40eb-8915-08dbf0b55f1e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: cTpG7Fp/4MgwkXbf2ti/J+pSH9iHKrTHaJBN2ePYsrh85JFiN2etQT+h2ogCDJJIXqei1QcekiKrZWGmmY65Wt/H4VkPJ7INJcoshYEagqnPqSKfYagta47x6+C/WBsBrd8kMd+viajvYoZduJcY2B54i3FsVNoY3d4ETV7ZydKov9EHXLIAe6GO9lKOgt4GhNNY6nlLv4rKqGtR/aBTKsBipqsPAaZbdlPgwDbEEdFQrqj13q2BPeDLpNK0hgzaLuKlzmyFSwMm5DXn5/69F+iI0DHlAyqY4tOgJRNXgRAKXRryry070lXVSYZAKjObIYUCR7OPHuINYMLcCheWTOHUmqx+U6UTv8N0pSWObxblL9S63Dkpyj4qHpRYPYOG3VTNOjgsI9fEzOb2+nioJxrd03pRa+Z+vZ7EgXEaIhrJbO04xTsKEitHB9/abarPLYJi121xrrbaeD/k6SLSu7laLI3NMIvDktw/m9pAbJh8SWrINskP0RcROG1KC4rWsPC3uMBvvfjoOiEIUhyx7hm8G8m/rmR6zyADalgSwccHzpxcdzUozcgr0sxKmw3DWuIzZyXUZ7Wr0jBwSPi6TNIAHQFl5mV4SajjNtbmHUnVlxPhEAXmp4dcxCGCmf3oy+lSiLkcqZNERwktE9b2sQ== 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)(136003)(396003)(39860400002)(376002)(346002)(230922051799003)(1800799012)(451199024)(186009)(64100799003)(66899024)(54906003)(8936002)(6486002)(316002)(6916009)(8676002)(478600001)(66556008)(66476007)(36756003)(66946007)(26005)(2616005)(83380400001)(53546011)(6512007)(38100700002)(6506007)(41300700001)(4326008)(2906002)(5660300002)(86362001)(31686004)(31696002)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?V21NOE1ack5wSFlyZjZnWUFEckdWcGJDcS9NMG9qUG5vZ1E2RmpyRFVpWHZk?= =?utf-8?B?NUR3MXZDWDRmMWdBazdBTTc1RzZES0VlL1RYb3BZdW9vd0QycHV5b2ZiUEZo?= =?utf-8?B?OHJFb0xZWU1JN3VQZ2p0eStpT0U3WDluT3ZDRWVjSVF0UVI3WVNDOEZYc2c2?= =?utf-8?B?bUI2NHlONEw1cFlldzRlVG5hNjJoT3NiOXg4R2YzczVkNGpkalFvKyt4Y1Z2?= =?utf-8?B?ZlRwdW5mRzYybTVwU1RWc2ZCMHBJTERxUjlVU3NuUEZaYXVscHlGbTVmKzZS?= =?utf-8?B?bkJTK3VaYVRLWlB3cmVPS1lyWjZyWkhuOU85TGdhb3hyTUx5SUthb3hrRDJL?= =?utf-8?B?OTYyUGMwajZpdmQyMnJTQjZBVlhpT1BQcTNBS0tRQUhZaGo1a1dlYjR0TUlt?= =?utf-8?B?RnJjWjhacHhSZ2U2ZGJhaDVxcW9ZdFd4MkFNSE5wRUkxdGhGemxia0dQVWVR?= =?utf-8?B?dWh0SXQ1bnhlcVlOeTZCN0grRUxUaU5DeStqYUgremRrRVBhbVVHY3hJby9H?= =?utf-8?B?YTk2MWptdGE2Wkl4Mk1USlVZbFVxeXNKS0FxR1JHbWNQaUZiczVsd0xFc0d1?= =?utf-8?B?OWNSS3BmQXJmQlprVStYbS9LMEJSUmpGZDdQaWwzMEd2YXBqZklndWZKOXMz?= =?utf-8?B?eEJVZHVtRERjZlZzaVpVTEdxUnJ0WG1aeXljUHhnYVM3a2xoc0doRFNLb1VM?= =?utf-8?B?c2psYVFPWUdXUE9TMEl6OVFLSkRISXJOeVVUWHd6ZGp0eHpZTFEwZk1VQTl6?= =?utf-8?B?bTJNb1d5cXg2dmtsOGxldllRQ1Z5Y2JjUElMbExIYkt5b0J2anpuNUxPZGMw?= =?utf-8?B?QTRsR3RXc1k1LzdsRTczOUJtVjdJTWluUy9BbUhKTnYzNGltYUVSQzBmUjFp?= =?utf-8?B?ZGlZYnRncEVQcnd1d1A3aEtIMTY4d1ZoTU1NMU5KZ21ZZGFYcG5wMmdieWQ0?= =?utf-8?B?QmhqQllmYnA3TExlMk10QnFFOTZ4elVQVkpLaGxFMDJZVHFjdVpJb2ZCV3Bv?= =?utf-8?B?NXVmc0pBYzAwd0Ntb0xaWDk1ZUx5enZOVkdMemMzdXZmQ2FGdzRFQmx1Q01h?= =?utf-8?B?TVFUQ0tSVXBUUzVSMHRRRFdTbEl6eUdDVWVqOGJoQmt5MVQ0Y2p2eGQzOEdr?= =?utf-8?B?ZHNYRWNPRjhhUW1wTnkyM0k1VDY0cG5GRHpsT0pwem45bjVQY0l0SUorZWtn?= =?utf-8?B?dC9YR1RYNXVqeGhLK1VJRGlKVGlMck9CdDBWOHNFMjZKbkVpbWc3elhpRng5?= =?utf-8?B?MlJpRXB4M2JKd29DSlBqQzdWVHUxOUEvUFNPdDFaZEdYdTBwYy9WMWZPc1Iv?= =?utf-8?B?dEVPOHhtNmRoVU92WUV3eXFxb3liMm9sSEw3MWJPYmJ4Q05tUEFGL0dFRmls?= =?utf-8?B?T3pTTjBUc0xrdWt6T3c5cWRqa3VReGxYei9xVW40UEtqRitySkE4R3dBbm5n?= =?utf-8?B?UHBMOVhMVjduSmQ0bitvOWdmSzdNWkk2NWFZbEJjS2JWVkd1bmYwR09nTUI1?= =?utf-8?B?QjMzM0JpWWxRdDZoTTFYdHhWWHRBaTZHQXZEWE55dGJZbVM5RU1HZHNDMkFJ?= =?utf-8?B?YXA3Snc2ZVZWUGJ5MGZRRWlzUW01dlFzeGIrbThkZHAvUHFmZlhQcElaQlgw?= =?utf-8?B?Ly9NcytwRHdERmt6bWUva2xoUHYzWExFbG1GWGkvMVlTUjRvNTZSUXZ0VGM0?= =?utf-8?B?YlZQT0kyOE5CblE0ZWNLa0twTEJ3YWlwRjRYdkM2Vmpta09BQ2hzSkRCWE10?= =?utf-8?B?eDdNN05FR0ZDTndaUVpRbWhINFRuVk1JcGRKaS9ZZmVIL1A3UmJvOHA2UnFL?= =?utf-8?B?SWtjZnJHaUl5UHpTUkhvc0tTclEzcU5sNUd3V3dEbnUvNkdTMFlIa09kZ2hs?= =?utf-8?B?SlhacUdNcm9WOG9mOStBc2JwaSt3MVl2cHY0WFo3d2cxZ0VQWDV4Y3AvTVRG?= =?utf-8?B?K2VsOEhxTXdXbWlaWmhhYnVJVkg2U2F2bHphTHpzdUUvTDI5VXV2NUowNkFO?= =?utf-8?B?UG8vN3Q0WGdqZ3dwYUNIMU5WTFFOUzNxbG1IQUhROXRiSFI3UkxxZzQ0OGZr?= =?utf-8?B?U3JZaGNRQjJyWW9yTmpFNFR6V1VsTG1qTCt2OG01OFk2WEJuZFU2em83YlV1?= =?utf-8?Q?WyNMTZdxuiAsHZw1Ir8901k2c?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 264f3a07-1a35-40eb-8915-08dbf0b55f1e X-MS-Exchange-CrossTenant-AuthSource: DU2PR04MB8790.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Nov 2023 08:29:58.0308 (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: Mh+SZVkgJDYUga1Fn57lxlXnCxl4G75OUmHhcPXJoZVgylie4KtbQuX1R9woIGOFjfMBzLIRMbgsJYx7oIk5fQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR04MB8476 X-Spam-Status: No, score=-3032.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,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 29.11.2023 04:08, Cui, Lili wrote: >> On 28.11.2023 14:14, Cui, Lili wrote: >>>> >>>>>>>>> @@ -10621,6 +10621,19 @@ putop (instr_info *ins, const char >>>>>>>> *in_template, int sizeflag) >>>>>>>>> case 'P': >>>>>>>>> if (l == 0) >>>>>>>>> { >>>>>>>>> + /* For pushp and popp, do not print {rex2} for them. */ >>>>>>>>> + if (ins->address_mode == mode_64bit && !cond >>>>>>>> >>>>>>>> I don't think the mode_64bit check is needed here, as without >>>>>>>> that REX.W cannot possibly be set (nor can a REX2 prefix be present). >>>>>>> >>>>>>> Done. >>>>>>> >>>>>>>> >>>>>>>>> + && ins->last_rex2_prefix >= 0 && (ins->rex & >> REX_W)) >>>>>>>>> + { >>>>>>>>> + *ins->obufp++ = 'p'; >>>>>>>>> + ins->rex2 |= 16; >>>>>>>> >>>>>>>> Please no new use of magic constants. Have a #define with a >>>>>>>> suitable name, and use that here. Also I think the comment you >>>>>>>> have ahead of the if() actually belongs here? >>>>>>>> >>>>>>> >>>>>>> How about " #define IMPLICIT_REX2 16", PUSHP/POPP can share it >>>>>>> with >>>>>> JMPABS. >>>>>> >>>>>> But what's implicit about the REX2 prefix here? >>>>> >>>>> PUSHP/POPP requires rex2.w ==1 and we don't want to print {rex2} for it. >>>> JMPABS has the same need, so I want to define a common macro for >>>> them, or NO_NEED_PRINT_REX2? >>>> >>>> Yes, we want a shared constant here (as much as we want a shared way >>>> of dealing with the need to emit REX2 in the assembler). Still, the >>>> naming wants to fit not only the goal (to suppress the printing of >>>> {rex2}), but also where the bit is actually stored (in ->rex2). >>>> Therefore its name wants to fit with the other names used for bits in >>>> that field. Which (to me) first of all means it wants to start with REX_ (or >> REX2_). >>>> REX_SPECIAL or REX2_SPECIAL might be an option, but might also be too >>>> generic (i.e. becoming an issue down the road). But I think this >>>> should give you an idea ... >>> >>> How about REX2_ IGNORED ? >> >> Perhaps. It's no better or worse than REX2_SPECIAL. Just make sure you add a >> comment explaining what it's to be used for. >> > > Done. > >>>> Then again, why is this constant needed for PUSHP/POPP, which have >>>> REX2.W set anyway, and hence that bit alone (when properly marked as >>>> consumed) should already allow to omit {rex2}. The question of adding >>>> a new constant (and how to suitably name it) would then be fully >>>> constrained to the JMPABS patch (for now, i.e. until such time that a >>>> 2nd insn appears which requires an otherwise empty REX2 prefix). >>>> >>> >>> The current implementation is that no matter whether rex.w is consumed or >> not, {rex2} will be printed as long as there is no Egpr. Of course, this place may >> be changed as discussed later. >> >> That's a bug then. If there is a REX2 prefix with just REX2.W set, and if that bit >> is properly consumed, no {rex2} should be printed imo. That's despite the >> same thing being expressable (in the common case; not here) with REX.W. >> Anything beyond that depends on the wider question of how to deal with >> _unused_ REX2 payload bits. >> > > For the last two instructions, although rex.w is consumed, we still need to print {rex2} to distinguish them. > > 0000000000000000 <_start>: > 0: 48 50 rex.W push %rax > 2: d5 08 50 pushp %rax > 5: 48 6a 01 rex.W push $0x1 > 8: d5 08 6a 01 {rex2} push $0x1 > c: 48 c7 00 12 00 00 00 movq $0x12,(%rax) > 13: d5 08 c7 00 12 00 00 00 {rex2} movq $0x12,(%rax) Well, no, I don't really agree (especially not for the last one). But that goes back to the more general question on the printing of {rex2} without also indicating unconsumed bits. >>>>>>>> The new Rex2 attribute is not only wasteful (it can easily be a >>>>>>>> new enumerator used with OperandConstraint), but also misleading. >>>>>>>> We don't just need REX2 here, but we need it with REX2.W set. >>>>>>>> Even if from the tc-i386.c changes it looks as if that was >>>>>>>> happening implicitly (presumably due to the absence of NoRex64), >>>>>>>> naming still needs >>>>>> to properly reflect the purpose. >>>>>>>> >>>>>>> >>>>>>> You are right, rex2.w is set in process_suffix, since there is no NoRex64. >>>>>>> >>>>>>> How about Rex2W? >>>>>>> if (i.tm.opcode_modifier.rex2w) >>>>>>> { >>>>>>> i.rex2_encoding = true; >>>>>>> i.rex |= REX_W; // add NoRex64 back, and set REX_W here. >>>>>>> } >>>>>>> >>>>>>> >>>>>>> Or just add a special judgment? >>>>>>> >>>>>>> if (t->mnem_off == MN_pushp || t->mnem_off == MN_popp) { >>>>>>> i.rex2_encoding = true; >>>>>>> i.rex |= REX_W; // add NoRex64 back, and set REX_W here. >>>>>>> } >>>>>> >>>>>> I'd prefer the latter over a new attribute (albeit once again with >>>>>> the comment actually matching code), and perhaps I view the latter >>>>>> equal to my earlier suggestion. >>>>>> >>>>> >>>>> Ok, put them in process_operands, there's already a special handler >>>>> here to >>>> change the prefix. >>>>> >>>>> diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c index >>>>> 0dde2a9ad44..2f2b1b04d10 100644 >>>>> --- a/gas/config/tc-i386.c >>>>> +++ b/gas/config/tc-i386.c >>>>> @@ -8715,6 +8715,13 @@ process_operands (void) >>>>> i.tm.operands++; >>>>> } >>>>> >>>>> + /* PUSHP/POPP requires rex2.w == 1. */ if (i.tm.mnem_off == >>>>> + MN_pushp || i.tm.mnem_off == MN_popp) >>>>> + { >>>>> + i.rex2_encoding = true; >>>>> + i.rex |= REX_W; >>>>> + } >>>> >>>> Well, I'm sorry for not considering JMPABS earlier on, but with that >>>> also needing dealing with, I think I view my alternative suggestion as >> preferable. >>>> That'll scale better when also considering that down the road further >>>> such insns may appear. Whether it's actually OperandConstraint that >>>> we leverage here is secondary (it's not ideal because there's nothing >> operand related here). >>>> I'd be perfectly okay with some other attribute being suitably >>>> overloaded, whereas I continue to think that introducing new >>>> attributes should preferably be limited to either cases where more >>>> than just two or three templates use them or cases where otherwise >>>> it's impossible to avoid ambiguities. From earlier changes of mine >>>> the underlying reason ought to be pretty clear: Each new attribute >>>> consumes storage, and with thousands of templates growth of storage >>>> requirements should be balanced with how frequently an attribute is >>>> actually going to have a non-zero value. For example, with >>>> is_evex_encoding() gone a brief inspection suggests that it might be >>>> possible to overload Masking (or maybe Broadcast): They're applicable >>>> to EVEX templates only, and the class of insns we're discussing here >>>> is never going to be EVEX (or VEX). IOW not much different from the >>>> overloading of StaticRounding. Such an overload may then well be >>>> named Rex2 (as you had it, and considering its intended use also for >> JMPABS, plus taking into consideration that REX2.W will be set simply because >> of the absence of NoRex64). >>>> >>> >>> Haha, StaticRounding is really special, I tried "#define Rex2Req Masking" and >> found that it will be used in i386-gen.c to identify EVEX (Broadcast...), then I >> tried VexW and SIB found that they are all used without precheck whether it >> was an vex instruction. Finally I wanted to re-use StaticRounding and found >> out that hulin already uses it for legacy insns. >> >> Hmm, I'm sorry for the trouble. I'm inclined to say OperandConstraint with a >> new #define it is then. Once everything's in I could then still see whether I can >> (reasonably) make e.g. Masking work here. >> > > Then I will create a new attribute Rex2 for it. ??? Jan