Re: [PATCH] x86/asm: avoid mnemonics without type suffix

From: H. Peter Anvin
Date: Mon Jul 15 2013 - 14:53:58 EST


On 07/14/2013 12:23 PM, Jeremy Fitzhardinge wrote:
> (resent without HTML)
>
> On 07/14/2013 05:56 AM, Ramkumar Ramachandra wrote:
>> 1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30)
>> changed a bunch of btrl/btsl instructions to btr/bts, with the following
>> justification:
>>
>> The inline assembly for the bit operations has been changed to remove
>> explicit sizing hints on the instructions, so the assembler will pick
>> the appropriate instruction forms depending on the architecture and
>> the context.
>>
>> Unfortunately, GNU as does no such thing, and the AT&T syntax manual
>> [1] contains no references to any such inference. As evidenced by the
>> following experiment, gas always disambiguates btr/bts to btrl/btsl.
>> Feed the following input to gas:
>>
>> btrl $1, 0
>> btr $1, 0
>> btsl $1, 0
>> bts $1, 0
>
> When I originally did those patches, I was careful make sure that we
> didn't give implied sizes to operations with only immediate and/or
> memory operands because - in general - gas can't infer the operation
> size from such operands. However, in the case of the bit test/set
> operations, the memory access size is not really derived from the
> operation size (the SDM is a bit vague), and even if it were it would be
> an operation rather than semantic difference. So there's no real
> problem with gas choosing 'l' as a default size in the absence of any
> explicit override or constraint.
>
>> Check that btr matches btrl, and bts matches btsl in both cases:
>>
>> $ as --32 -a in.s
>> $ as --64 -a in.s
>>
>> To avoid giving readers the illusion of such an inference, and for
>> clarity, change btr/bts back to btrl/btsl. Also, llvm-mc refuses to
>> disambiguate btr/bts automatically.
>
> That sounds reasonable for all other operations because it makes a real
> semantic difference, but overly strict for bit operations.
>

To be fair, we *ought to* be able to do something like:

asm volatile(LOCK_PREFIX "bts%z0 %1,%0"
: BITOP_ADDR(addr) : "Ir" (nr) : "memory");

... but some older version of gcc are broken and emit "ll" rather than
"q". Furthermore, since that would actually result in *worse* code
emitted overall (unnecessary REX prefixes), I'm not exactly happy on the
idea.

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/