[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 08/11] x86emul: handle AVX512-FP16 conversion to/from (packed) int16 insns
- To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Thu, 11 Aug 2022 08:33:59 +0200
- 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
- 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=G7jJ+P82HsC43H2tehMpBIbZLspeOZBz755EeWgzy0o=; b=CORt00xSONAieirTEfJ/tWrA/tWMrjCJwinT2VOi1oazClxKpFF8xZBCl02fuCVKLPjo9nArpB5egYieOIUtMtPNHQf2CuCu12sTKrgr7QaPVIoHY3SOiapwu700MiiiDcqjidbuQG2vHiMfzD+eebdrzZ31MInoSHAzwN16uqgWdUIwpVaqirp6VFie1gynyNCZSX08Skm/1MjUKwyhp8hboTYGur12je/NfqZvm7lMtagfQOumE2KCemu8kJcFvDegFaZLxRKhODH1fqQ6ueYLYSwAn0f70PKsqRv+NayX2pCvl7wxy/yMmE39Xo3DGz+5YZml4m20Own/C388QQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jYarP3jHLAV0qcrZBAWX4KaCZumzRQcVRkoikrVy0CfrRGeTFMsXyYfFATbwVvvAL2fNGoJ4ihPUZlUH8wIDtsWSCA5ETytLM2USxR4yrKnyq8Mo6Bw0Ahf4WpBH82HE7cU04rZ1GfksupHLvRxFsVBbQdbg9uygYYbRGJ5T/Ca+AEUWOmpq6giHzuUiFMfzlCWjgfp+CgsUYVi9QinfoL7m1NWdARKyrMuEUfkTzNGJZp/zqpAwBH+NPw1JqOWMhgt5WFEekBG5R3WBS5/XNdcXMCpPeUUjuhpJ3g0JmJe8Mktukx3DLNpm69rtoaCTmqmc6hD/SiCuKt37y1GBXw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Thu, 11 Aug 2022 06:34:17 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 10.08.2022 21:01, Andrew Cooper wrote:
> On 15/06/2022 11:30, Jan Beulich wrote:
>> These are easiest in that they have same-size source and destination
>> vectors, yet they're different from other conversion insns in that they
>> use opcodes which have different meaning in the 0F encoding space
>> ({,V}H{ADD,SUB}P{S,D}), hence requiring a little bit of overriding.
>
> At what point is sharing the opcode tables going to be not worth doing?
Very good question. I've not been able to set, for myself, a good
threshold. The vague plan that I had was to wait and see what the next
uses in map 5/6 are going to be, and then decide whether to introduce
separate tables. (And if still going with overrides then, re-evaluate
on the subsequent set of additions. But basically always with a full
new set of insns in mind.)
Jan
|
