From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2052.outbound.protection.outlook.com [40.107.20.52]) by sourceware.org (Postfix) with ESMTPS id 0CD9F3858C20 for ; Wed, 25 Oct 2023 15:59:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0CD9F3858C20 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 0CD9F3858C20 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.20.52 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1698249586; cv=pass; b=XfcY4nLyUtGj/4Abdkby9eAZNUuIVRgqMfkMTqu1A4kzYI4XCJxS7zXzeHkAAeXUAEjbee6oteBLPoAyz9PLGDwkDhhgKsf7ajzk97w5oG0DgAeDphWPYzeNy6Azz2FLuOYp+OG5JRdsZgJM3ZpkIKXLnoskdj7B5RXwBfS/f9g= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1698249586; c=relaxed/simple; bh=q+D32UoJ/gMEOd3krhQ/EC+saU+qwxi9/VEFLP22yuI=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=kleOe557kkAFFk5cMqYR2HdeTvAdGgdyew0c2fM8Wm1/qSeh/Luv2zos9ULN3nuAwjsXFCDyMPFZMFYmEkA0MZriG/7jKu7Q+wI6uvNrmRqFCISP779l9aOBksi2EcbwE02fz+1fBxCFtdzGymOFS+ioF6S3h2wqUodYTKSsbGo= ARC-Authentication-Results: i=2; server2.sourceware.org ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P9+lLLJQZ6De8Z93FlZ81QOW2BwgudMt2YyvjCmgM2cvUt5Ff3VsU08YoKZMOXzDqc60i9Rv4esWE5tMypGVQdWRIuuOJapQSNS6y7QQS0NivQ5PZpx0C0Hzv51ELeqp6bsrHVL3y7K6Y3y4uHqM76onAc2i17NFsPiipEQl256QCS26iyiRgwh0ncGRDOaBpidiu6QOBig8oBoFZP6iNoQHdgSCryBfdBxMjEgF66GZSGboCsAH+kyOiLq59x2XX1s2Xwzf1/J1q6O7txgnSl0ML5UQ14Sh6qRlmuExQ1sFC/ogJIN+2Wk6F2I7/Igu3XfTh2KI5fdI6MGnMAr3Lw== 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=vbqW3w1GHyaF1TgQJzgxsjZVFmoZ1a7RzoWRM2zfeXI=; b=HcClDqKBpnxGY+F0GGqmqxOxJrQniGrvJYFf29tiBDVaBf50lTnao98TFU6a/ZFuKO4q50MvzVF2IFpPNaOCWObblTbfHm2C3QHBzrJv31mKaIL26PPuo+m5XtTyUuBCmkPfLOWQ1YSp6HNbTB19AMHiu6AZLyZIZ9n1l3Vm5MADVH6Jl8AMSvJ05uXpby70hfLhPE54Me7uSk5Gar3zDB4KkW6R/hlvxR5KRR1gb2y/xPnNLprL1VYW6Bevgaosn5qP72LcVHOZ4CtxFz2rkMMqziZufhmFMzM7rUYfAQ5N3Wlakqudsrw+dzZ1lT4Y2FWlli04+511L8m8gAnT+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=vbqW3w1GHyaF1TgQJzgxsjZVFmoZ1a7RzoWRM2zfeXI=; b=Rdg/T7FMO7pdIOQRaQeYUQpUvw2AAda6AKa3VCx8OEyIJDfZkPW2LTxbvBx0OEBkxD4R35xmhG9i4R1AhsyYEAZ/BSgFD39UYYhkNUpLB07JRSZm9jIn175DvM2VuCWDk4wO9tLkoJHF9hz+BhvYs3a8ipaonfkZlVo9/eBxKEnHiz4gQFihtU2CdRpmBq6a1pYexT605W1BV/ZU7y2mqqVyqIn1XfdiaK8PaczmD7oeA8f6bUZ8w6Duh4XskdaClKoeTwOUmJyLVQuw0f0Mv2P6qA/42WNwBZp9idv/1nOw2IAiqzFxqwCnefTT7SlGYsz6dEgs/0dUz8AhmZO+xg== 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 AM7PR04MB6824.eurprd04.prod.outlook.com (2603:10a6:20b:10e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6933.11; Wed, 25 Oct 2023 15:59:42 +0000 Received: from DU2PR04MB8790.eurprd04.prod.outlook.com ([fe80::d924:b650:a2ad:7b25]) by DU2PR04MB8790.eurprd04.prod.outlook.com ([fe80::d924:b650:a2ad:7b25%3]) with mapi id 15.20.6933.011; Wed, 25 Oct 2023 15:59:42 +0000 Message-ID: <3e6558a8-56a2-f81e-da94-a978702ffc00@suse.com> Date: Wed, 25 Oct 2023 17:59:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH 4/8] Support APX NDD Content-Language: en-US To: "Cui, Lili" Cc: "Lu, Hongjiu" , "Kong, Lingling" , "binutils@sourceware.org" References: <20230919152527.497773-1-lili.cui@intel.com> <20230919152527.497773-5-lili.cui@intel.com> <9d317289-6d83-3f9b-ef34-af574e798a3f@suse.com> <86df39d7-e555-7362-5e2e-ed9e22661407@suse.com> From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: FR5P281CA0057.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:f0::15) To DU2PR04MB8790.eurprd04.prod.outlook.com (2603:10a6:10:2e1::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU2PR04MB8790:EE_|AM7PR04MB6824:EE_ X-MS-Office365-Filtering-Correlation-Id: e4a28a49-d652-492d-e72b-08dbd5736671 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ErCzXvDshg3b2aNKNCZRH794CLlTTNU6ahoE36C592VjOCDEX2BKWZTIQN8mDE+CGs32iGnV64vnYwJdecprv9k4yMn03nin1ys9MZuLDVK4d0wYirlZyPFpzzcvLa4GvDxQ1ls/zk2da2DbbFXTz2/5TrUgV//xSBfdK0cRxkSKHLH21/iqfo3ij0nGUtv5OmuhbpZY7zZzJRncgAKIcYF01afDNq2tH05zwcEHeqCy3Uqbut89qd33PYeWcVN4vOJhBU4YRJKs31vIsmOQHvxMz7DSgWd7exWZlRpnvI8ANwyOy9RcVjL5i+50h3oU2GPahYVLfN3prr90Wz+1QQ0ORZrNjIfWOtMwdXhMjeoj+9lgoHOpCy+FH5STE97/9FTaCF133yO59310BKX7G7n0fi7iPHIAp/ONp3JiaUS5UdExWUDz0NpAuljjW5ojP9nqjZHMXO0f9Y1tIQD7B/ruycjJo34rMhYsGm5Q1pm/iRhrskFbPumELcp2E9BCItcrwly/RHATCGCMdUFwY+ZcCfF0VOVbBO+3RlnTx/ZcnfaHeHYY+TEKOEPJgFRGoGRLpRmPxVM5zzdH0x8qF7QOIvSQqrNXcM+qEzDyJkB5ZUyC5svl6Cmy6qh6+ceC5MY1veHQOzYeR+GxWPoN/Q== 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)(396003)(39860400002)(376002)(136003)(346002)(230922051799003)(64100799003)(451199024)(186009)(1800799009)(41300700001)(2906002)(38100700002)(66476007)(31696002)(54906003)(66946007)(66556008)(478600001)(6916009)(6506007)(53546011)(6486002)(83380400001)(6512007)(36756003)(86362001)(5660300002)(2616005)(8676002)(8936002)(4326008)(316002)(26005)(31686004)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aE02TFlTK25mbHJlcUdHQk51K1lKZTJMeUNqQ3pyQzk5N2Zsa2twTlZ1VlRB?= =?utf-8?B?SkZIenZuNERObWdaclFSVTdlRm14NU1mVXg1alRnZ0IvTDliTGFSU2Rhei9S?= =?utf-8?B?b004cFNQRDBDUDVSK3l5RXV0S0VLQ1Q3cktpM083UnpadVRYenJBSExPZ3pa?= =?utf-8?B?TERBemhTQndwQUpOcWpmYjJiRTZ4Vk1NQU5CZC9RVTROZytTSGJNUXZnVGFr?= =?utf-8?B?b3p6eGxHNnVPM2ROdVJDdVI5cFV2ZWY5bVduaURXWjhIdHdhQndRa2ladk1Y?= =?utf-8?B?aTVORDY2Ry9NT3VnanlyOVFQb1JVVGF3K3plekpaVGFmRmZmWU9FTUYyQTdY?= =?utf-8?B?N29yTFFyMUsrd09oeFVvRExyU05rVTVJeVZmYWdTZFRRR0tCUnJpdzkxUlJz?= =?utf-8?B?OHppOHRaaHFiUjB6Y093S09tSEN2RVE2eG0yOUpoWGNVZmx5LzZzQjNzN2xT?= =?utf-8?B?L290aGd4TEM3ZW03Unp2VnVlNEZCRmI1Q0dsY3YvczVMOVRYVFRRRmRpYXF2?= =?utf-8?B?cGpqN1hLMU5TZmFKRnpNbjZqRi81a21ubmVIbThRN3pjQ05md1JoQVdGZWdX?= =?utf-8?B?UHdoZUVmNmRFUTA2cVBNaGo3ZHhrNHhxUEFGR00wQzNNY093RU1tajNXMzlF?= =?utf-8?B?QjN4ZnNkSGhEZVp6WDhUL1hXSHBPbUpTS1d1WEpGOStYcHhmU0ZvRk4xWTlq?= =?utf-8?B?MVJJdjF3VVFsMDFyeEZsN2ttcE1vUFBNY0gzb1VIQWVWQmZ4UVA0V3BOaWZS?= =?utf-8?B?RkRDcUxKWHJKVDVWUU9HbEowRGh6aEtqR21XMlN1T3JscW5CanQwWlI4Y25I?= =?utf-8?B?aGtiS2p0V1pxdVlpeCt5KzlyME1WQ3A5Qngrc3lBais3dHpQNGtLL2U1Q09L?= =?utf-8?B?UkJCVVhsWjJhWld2dmRSZ3pJQkNJUSs3K2NITHpsOVk4OGJKU3ZVSXpieG1x?= =?utf-8?B?WndYSmpjVlNLTFFxamZiNnZKZVhmbWwyaE1YZWkxUERCcmk2MDJrODZOK1p4?= =?utf-8?B?NVh4SXlTWW5DWmgrejBROU1YUlorbVplYW9ycktrU0hNbnBjamhUUURuK2dI?= =?utf-8?B?ZEhJclpQRWs0UW5hKzFDdmhaWVE3T3R3YnVldExDbXh0SUJGVFYzR0IxWUVx?= =?utf-8?B?Ylo4KzdpT0xxc25jbEtGQW5TTUR1V1I3aEp2ZlpxVEdEcVNpdGNjcjNjeHBq?= =?utf-8?B?WUZhbnVvZWJiZEU3ODVsN2EwODNHckgwR0Q5Tm5OUWJFTzB1YXpEL1dxeUF3?= =?utf-8?B?TlpmbUVVcTVIRmRpckc0VHZodzNYY2N0TVlwY3JKcEk2OHBLTXRQMDlKcWpW?= =?utf-8?B?b0EwQ1pCSW0vMDR6Q3NBdTlxaEEranlVQnVzU3pzY25VbHN2bkJlNWkwbjFp?= =?utf-8?B?K3k0OUxMT2VLcThpVzZPOGloM2x6UzJaNUQ5SDZFNXRjY3VmRVFtUFNKSkhs?= =?utf-8?B?YmQ1SkQxeFl0SWwyUzVoRlU5WFJ5eGVUL0RSMUlBN1l6b3k3MzlxdVdYa3dp?= =?utf-8?B?dFVMZTN6VERaaDRYRHdxQnV1ZUJEZ2VKSlVBaXRCM2FONUpkNmE0N3gwUFpq?= =?utf-8?B?UVBiOEh3NVFQbWhxbnB2V2xyR2cwMTFxSERiTVJEK2llajBaRGhrQUlvZ1dJ?= =?utf-8?B?QzZXZTBYTnlLL2FpMHRCSFVtMllqRXphUm4yN0kzL1YrMHBBQllkZ2VtWUJi?= =?utf-8?B?NkQrK1A3MHFOQk4yQ0xYSjd5QnZIRm9yakZJN2lNdnR2d08xOVArQmREWkNi?= =?utf-8?B?YUw4UzQ2bFZCcVliKzNkdnFkaVI1QWVSYWJkWGVNdG9jdnBXVDVyRy9pR0R3?= =?utf-8?B?NlRBN1hZNk5vYUE3Rm5DWElCOHlSV1RCQW1Hajg0U0NlaWtWWm8xOVpocVlL?= =?utf-8?B?NjIzRXNZQU1MdGtiSE5MSVplWVpXRTFVTEtVa3U2RTNjWXJyNkJSeHloT1Aw?= =?utf-8?B?QjhYNUo0WVBzQUQrdGF2T28rWVdESUlndzFEemEyMUZ0eXVCRkpWK1VKRHl0?= =?utf-8?B?ZE54T0doZ2JGa2ZEVEtoNWc5YkQxL0IyZE5yVXY3blFyNVBQaThXY0VrdEFv?= =?utf-8?B?N3g3UDVJVWppVzlYY3BSUkgvdVYrUHcwN2plMmxvZ2JXMTduUERLdUZrY2p1?= =?utf-8?Q?PlY/1iNbiZV4wduA8KZIpre52?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: e4a28a49-d652-492d-e72b-08dbd5736671 X-MS-Exchange-CrossTenant-AuthSource: DU2PR04MB8790.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Oct 2023 15:59:42.0705 (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: gipEzDXYwSGzeJOm/FPQL0EjU9bOhPGCna5kTdJE4NGNj/Fw8UWUacJUDUHODpVzuonSmYTxlWKuFtoUhO6NVw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR04MB6824 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 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 25.10.2023 17:49, Cui, Lili wrote: >> Subject: Re: [PATCH 4/8] Support APX NDD >> >> On 25.10.2023 10:10, Cui, Lili wrote: >>>> On 22.10.2023 16:05, Cui, Lili wrote: >>>>>>> --- /dev/null >>>>>>> +++ b/gas/testsuite/gas/i386/x86-64-apx-ndd.s >>>>>>> @@ -0,0 +1,156 @@ >>>>>>> +# Check 64bit APX NDD instructions with evex prefix encoding >>>>>>> + >>>>>>> + .allow_index_reg >>>>>>> + .text >>>>>>> +_start: >>>>>>> +cmovge 0x90909090(%eax),%edx,%r8d cmovle >>>>>>> +0x90909090(%eax),%edx,%r8d cmovg 0x90909090(%eax),%edx,%r8d >>>>>>> +imul 0x90909(%eax),%edx,%r8d >>>>>>> +imul 0x909(%rax,%r31,8),%rdx,%r25 >>>>>> >>>>>> What about imul by immediate? The present spec is quite unclear there: >>>>>> The insn page says {ND=ZU} and the table says 0/1 in the ND column. >>>>>> >>>>> >>>>> We don't support it yet, I put it in RFC. >>>>> ... >>>>> 2. Support APX ZU -- In progress >>>>> 3. Support APX CCMP and CTEST -- In progress ... >>>>> >>>>> About 0/1 in the ND column, it means ZU can be 0/1. >>>>> >>>>> IMUL with opcodes 0x69 and 0x6B in map 0 and SETcc instructions >>>>> Although these instructions do not support NDD, the EVEX.ND bit is >>>>> used to control whether its destination register has its upper bits >>>>> (namely, >>>> bits [63:OSIZE]) zeroed when OSIZE is 8b or 16b. >>>>> That is, if EVEX.ND = 1, the upper bits are always zeroed; >>>>> otherwise, they keep the old values when OSIZE is 8b or 16b. For >>>>> these instructions, >>>> EVEX.[V4,V3,V2,V1,V0] must be all zero. >>>> >>>> So ZU indeed isn't just a typo there. For 32- and 64-bit forms, is >>>> EVEX.ND then simply being ignored? The ZU really is meaningful only for >> 16-bit forms, aiui ... >>>> >>> >>> EVEX.ZU should be ignored for 32-bit and 64-bit forms. For imul (in spec 6.30 >> IMUL), EVEX.ND stands for ND or ZU. >> >> In cases like this, where ignoring bits is kind of unexpected, the spec would >> better say explicitly (on the instruction page) when a meaningless bit is indeed >> ignored, rather than being reserved and causing #UD. Note how even the text >> in the APX-EVEX-INT section leaves open (or at least ambiguous, by not >> mentioning the case) whether SETcc with a memory operand ignores EVEX.ND >> or causes #UD when the bit is set. >> > > Sorry, my previous answer was inaccurate, EVEX.ZU will not be ignored in 32-bit and 64-bit forms. > > Prior to Intel® APX, the following rules apply in 64-bit mode when an instruction’s destination is a GPR and > OSIZE < 64b: > 1. If OSIZE is 32b, the destination GPR gets the instruction’s result in bits [31:0] and all zeros in bits > [63:32]. > 2. If OSIZE is 8b or 16b, the destination GPR gets the instruction’s result in bits [OSIZE-1:0] but keep its > old value in bits [63:OSIZE]. > > The ZU indication described in items 2.(b) of Section 3.1.2.3.1 does not introduce an NDD. For those > instructions, EVEX.ND=0 keeps the current x86 behavior, but EVEX.ND=1 forces the zeroing of bits > [63:OSIZE] for any OSIZE < 64b While described differently, that's still the same behavior as before for OSIZE > 16b, isn't it? Which still means the EVEX.ND is effectively ignored in those cases (and could hence as well be reserved). >>> I think ZU makes sense for both the 16-bit form (imul) and the 8-bit form >> (setcc, I'm not sure if imul supports it yet). >> >> No, IMUL by immediate (or actually any IMUL with multiple operands) doesn't >> support byte register operands. For SETcc the ZU aspect is pretty clear and >> doesn't even need expressing by new syntax in (dis)assembly - you can simply >> distinguish the two forms by using either 8-bit registers (no ZU) or 32-/64-bit >> ones (with ZU). In principle that's possible with IMUL as well, of course, but it >> may be deemed a little odd: >> >> imul $17, %dx, %cx >> imul $17, %dx, %ecx >> >> Yet personally I'd still prefer this over adding e.g. {zu} on either the mnemonic >> or the destination operand. Question (as with the way to express >> {nf}) is how other assemblers are going to handle it. (Would be quite nice if >> the spec could at least give more clear hints towards suggested syntax, but >> that hadn't been the case already with the syntax extensions needed for >> AVX512.) >> > > I will add suffix “zx” (for the Intel syntax) or “zwq” (for the AT&T syntax) to the mnemonic: > > Intel syntax AT&T syntax > imulzx rax, word ptr[ rbx ], 0xab imulzwq $0xab, (%rbx), %rax For Intel syntax, unless you happen to know that MASM is going to go that route, the "word ptr" is sufficient for disambiguation, and no suffixes should be accepted (gas) or be output (objdump). For AT&T syntax the case with a memory operand indeed requires some means to disambiguate; as asked before, I wonder if your approach matches with what other assemblers are going to do. Jan