[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] x86: correct asm() constraints when dealing with immediate selector values
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Tue, 28 Jun 2022 14:59:12 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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=F4WQVfKaHh29/UDMHLsgwd0cfxFswnebgrRcID3Ts1U=; b=EYfWsEyImzKswLS6H8WsmuqZE0egoTaXk+yrhtluZLdvEnxf1oEhUjcC/PiSE8Mwot2gByB6VhX++IjN5Ngb2hcx3YsIVf2JEWfsKtLTOVnvtWED6AqpwhZiRVbmYiBzBXac+hxkeQZD5yJpdXzwsXLfNc/q4hSnAhVeFOJZlPEaPk8uIdzA80HDaWnZfVJjhdBh2zm4YLmOG036Av0oxLCXViGtVBukl12Qnkd0uZCu7q/m1oQuAChWHFVOjFpRzaGFfxvKsP4NzVOCZU3+5XUUyCq5Y0Yi8eJfFic3BpXFJkihhRhIB950lQzQ1U8GQVTb3LPhy8K46dqSCBucVQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MyTBqCAi5qFO2CNOUTLbGnvNuglnY6WdF7qHonpUiwFL4tuXNyt3UKX6IDIET8d7Y7S3PfsSpD/09NSn3/AHNmActjk5z+QrE+0Sf54RNz78v9maqWvEjUAGfCw6TfdgZ9pv78cCEJ1VA4LDpbZtZJe+UT6rUAPY/YhF56NIlRCOrOHp9HkkAafq4/iM6gZlGoWDznvPhR3uCHoBKQWK7EfI4bsHhJ4YuyaCUWbAJ3R4wmO0B7BJMLddults6miPjENwNuXYs6RT36SGg75NRPC3IUEAl+Fdn8JMc293DXTYo3J1C01XwpuW95mutLlaX0Lts4V3c0snzlgxUIgcUw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
- Delivery-date: Tue, 28 Jun 2022 12:59:29 +0000
- Ironport-data: A9a23:4K3G4a+SG79XSV1kC/X0DrUD9H+TJUtcMsCJ2f8bNWPcYEJGY0x3y GscWD/Va6yMZWLyLoh/OYqyoxsF7cfQz9JnHAI6pXw8E34SpcT7XtnIdU2Y0wF+jyHgoOCLy +1EN7Es+ehtFie0Si+Fa+Sn9T8mvU2xbuKU5NTsY0idfic5DnZ74f5fs7Rh2NQw34LpW1rlV e7a+KUzBnf0g1aYDUpMg06zgEsHUCPa4W5wUvQWPJinjXeG/5UnJMt3yZKZdhMUdrJ8DO+iL 9sv+Znilo/vE7XBPfv++lrzWhVirrc/pmFigFIOM0SpqkAqSiDfTs/XnRfTAKtao2zhojx/9 DlCnb7qFQ5zMobpor4QEBxGIhB4Hfdp1aCSdBBTseTLp6HHW13F5qw3SWoRZMgf8OsxBnxS/ /sFLjxLdgqEm++93LO8TK9rm9gnK87oeogYvxmMzxmAVapgHc+FHvuMvIABtNszrpkm8fL2f c0WZCApdB3dSxZOJk0WGNQ1m+LAanzXLGEF+AjF/vtfD277/jco/qfsAevpfd2Gf/hPw3eVp WGF4DGsav0dHJnFodafyVqujOLSmSLwWKoJCaa1sPVthTW71mEVTREbS1a/if24kVKlHcJSL VQO/SgjprR081akJvHiWzWorXjCuQQTM+e8CMU/4QCJj6HTugCQAzFdSiYbMYN/8sgrWTYty 1mF2cvzAiBiu6GUTnTb8aqIqTS1Om4eKmpqiTI4cDbpKuLL+Okb5i8jhP46eEJpprUZwQ3N/ g0=
- Ironport-hdrordr: A9a23:WoRk9qmYEWjzVtb68YQgXghRMZPpDfO3imdD5ihNYBxZY6Wkfp +V8cjzhCWftN9OYhodcLC7V5Voj0mskKKdxbNhRYtKOzOWw1dATbsSlLcKpgeNJ8SQzI5gPM tbAstD4ZjLfCJHZKXBkXaF+rQbsb66GcmT7I+xrkuFDzsaDZ2Ihz0JdjpzeXcGIDWua6BJdq Z1saF81kedkDksH7KGL0hAe9KGi8zAlZrgbxJDLxk76DOWhTftzLLhCRCX0joXTjsKmN4ZgC D4uj28wp/mn+Cwyxfa2WOWx5NKmOH5wt8GIMCXkMAaJhjllw7tToV8XL+puiwzvYiUmR8Xue iJhy1lE9V46nvXcG3wiRzx2zP42DJr0HPmwU/wuwqXneXJABYBT+ZRj4NQdRXUr2A6ustn7a 5N12WF87JKEBLphk3GlpT1fiAvsnDxjWspkOYVgXAae5AZcqVtoYsW+14QOIscHRj99JssHI BVfYzhDc5tAB2nhk3izyhSKITGZAVyIv7GeDlJhiWt6UkYoJgjpHFoh/D2nR87heAAotd/lq b5259T5cBzp/8tHNxA7dg6MLuK40z2MGbx2TGpUCPaPZBCHU7xgLjKx5hwzN2WWfUzvegPcd L6IRhliVI=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Mon, Sep 13, 2021 at 08:26:21AM +0200, Jan Beulich wrote:
> asm() constraints need to fit both the intended insn(s) which the
> respective operands are going to be used with as well as the actual kind
> of value specified. "m" (alone) together with a constant, however, leads
> to gcc saying
>
> error: memory input <N> is not directly addressable
>
> while clang complains
>
> error: invalid lvalue in asm input for constraint 'm'
>
> And rightly so - in order to access a memory operand, an address needs
> to be specified to the insn. In some cases it might be possible for a
> compiler to synthesize a memory operand holding the requested constant,
> but I think any solution there would have sharp edges.
>
> If "m" alone doesn't work with constants, it is at best pointless (and
> perhaps misleading or even risky - the compiler might decide to actually
> pick "m" and not try very hard to find a suitable register) to specify
> it alongside "r". And indeed clang does, oddly enough despite its
> objection to "m" alone. Which means there the change also improves the
> generated code.
>
> While there also switch the two operand case to using named operands.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
Thanks, and sorry for the delay.
Roger.
|
