[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] x86: correct asm() constraints when dealing with immediate selector values

  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 10 Sep 2021 08:59:42 +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; bh=y94f08PmpbGymxwcg2LlCnG9x+YXIiqERiRQjkQp8sQ=; b=T1KZ7AzUeK7gN0rhkqg5tlZGMqpja1hqj6MFNwqXWdOohZZjDCQ84GVtGTIU9g3hy3p3Kw0c9q2zVSNOI4W8F5PKgyP4wXgYq9ePWsDZjsCfG0ATwjl8FVaztaMbVlHA6Y01JMleXCitpFkSje/YGX2cW39vSglZfGrxxXIsaWPM3B8tF+5ujz5McDZN0hfPvPlLZ6cqRUnqLOD3Q2etvsnBE2rt3ufeJpATRrlaYHnVY15a15TMkZ5GxGqNVtcLQRIvUxKm6b5SMRH1TwQnAK3s+EHaqAj/ImtVW5cNA2rVLqB54YPxoRQhOlHT1+7NatRfRkxowzmx86rdCDKa5Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ho4Z02Gs+I05vsATkC0xAtOD9bLqS2UOH31G5zNi4vh/XVO6mlRUxjLDNSR+mIeTSKHmBIItux8oHFMciKnPZYeiaHTk/FmJQxZn14Wz/ZpCUz+2InvJcKDv2uLA/giZ6J6dBinMVR4Pk4P9qrFVdQSnSa0vh6NvCD5itgupb7pBCr8bL0U1v+YOKKykDJoH4H7a4gTC1/Ln3DuAk0wKpeAfKAwVpkrYrzF7kZjY+XN/+HqR5q53yV+vZbO5RnXF59fMx5x11rFmG8MVfGF04t344HtSlrgh+uhRJXIbxzjt7Y2tEtJrUW/ogaeH1W5ZW9ezxOkoBYWAW9lHHB8DNQ==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 10 Sep 2021 07:00:08 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 09.09.2021 21:31, Andrew Cooper wrote:
> On 09/09/2021 15:56, 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.
> It's precisely what happens in the other uses of constants which you
> haven't adjusted below.  Constants are fine if being propagated into a
> static inline which has properly typed parameters.
> Or are you saying automatic spilling when a width isn't necessarily known?
>> 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".
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> I'm slightly surprised you didn't spot and comment about what Clang does
> with this.
> https://godbolt.org/z/M4nrerrWM
> For "rm" (0), clang really does spill the constant into a global and
> generate a rip-relative mov to fs, which is especially funny considering
> the rejection of "m" as a constraint.
> Clang even spills "rm" (local) into a global, while "m" (local) does
> come from the stack.

Which leads to a lack of diagnosing bad code, in e.g.:

void movq(unsigned val) {
//      asm volatile ( "movq %0, %%xmm0" :: "r" (0) );
//      asm volatile ( "movq %0, %%xmm0" :: "m" (0) );
        asm volatile ( "movq %0, %%xmm0" :: "rm" (0) );

The "r" variant gets diagnosed (at the assembly stage, as a 32-bit GPR
is invalid as an operand to MOVQ). The "rm" variant gets compiled to a
64-bit memory access of a 32-bit memory location.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.