[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts

Stephen Checkoway s at pahtak.org
Sat Jul 13 10:15:30 PDT 2013


Eli Friedman wrote:
> The reason it's the right thing to do is that the mem/imm forms of
> btsw and btsl have exactly the same semantics.

The Intel documentation implies that this is the case:

> If the bit base operand specifies a memory location, it represents the address of the byte in memory that contains the bit base (bit 0 of the specified byte) of the bit string (see Figure 3-2). The offset operand then selects a bit position within the range −231 to 231 − 1 for a register offset and 0 to 31 for an immediate offset.

However, this doesn't seem to be true if the immediate value is greater than 15. See the attached imm.c which prints the results of bts m16,imm8 (btsw) and bts m32,imm8 (btsl) with the immediate in [0,63]. For btsw, only the least significant 4 bits of the immediate seem to be used whereas for btsl, only the least significant 5 bits seem to be used.

In contrast, bts m16,r16 (btsw) and bts m32,r32 (btsl) are identical for bit offset operands in [0,63] and are likely identical for [-2^{15}, 2^{15}-1], although I didn't actually check the others. See the attached reg.c which changes the immediate constraints to register constraints.

btr behaves similarly.

For the memory, immediate form without the suffix, it seems like the options are
1. If the immediate value is in [0,15], use btsl/btrl since it saves a byte, otherwise error;
2. Follow both gas's behavior and the Solaris assembler manual Jim Grosbach linked to which stated that unsuffixed instructions are assumed to be long and alias bts to btsl and btr to btrl; or
3. Always error even when there is no ambiguity.

I have no opinion on which option LLVM should follow.

-- 
Stephen Checkoway



-------------- next part --------------
A non-text attachment was scrubbed...
Name: imm.c
Type: application/octet-stream
Size: 576 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130713/1669e7a7/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reg.c
Type: application/octet-stream
Size: 578 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130713/1669e7a7/attachment-0001.obj>


More information about the llvm-dev mailing list