[PATCH v2] X86: disambiguate unqualified btr, bts

[Jim Grosbach]

On Jul 15, 2013, at 6:24 PM, Stephen Checkoway <s at pahtak.org> wrote:

> 
> On Jul 13, 2013, at 12:43 PM, Tim Northover <t.p.northover at gmail.com> wrote:
> 
>> The problem is that behaviour seems to violate the intended design of
>> AT&T mnemonics.
> 
> Is there an actual specification for AT&T syntax? The one Jim Grosbach posted to the list explicitly says that instructions without the size suffix default to l. I don't see any reason to take that as the definitive definition of AT&T syntax but then I don't see anything that would indicate that gas's behavior is incorrect.

Yeah, that’s the best reference I found, but there may be better. If there is, I’d love to see it (and have a link to it on the llvm.org pages somewhere).

> 
>> If we make btr default to btrl, shouldn't we do the same for every
>> other pair?
> 
> 
> Based on the Solaris doc, yes.
> 
> On Jul 15, 2013, at 7:18 PM, Jim Grosbach <grosbach at apple.com> wrote:
> 
>> If adding aliases for these mnemonics is the right thing to do, then an argument can and should be made for that independent of gas’ current behavior.
> 
> I think the best argument is the one Linus made (modulo being rude). If the assembler is a tool for humans, then all else being equal, it should operate on a principle of least surprise.

Yes. I suspect there may be disagreement on what constitutes surprise, but that’s a more philosophical debate and tangential to the current discussion. 

> 
> bt $n, mem becomes
> 1.  btl $n, mem for n in [0, 31] and

This seems totally reasonable.

> 2a. btq $n, mem for n in [32, 63] or
> 2b. btl $(n-32), mem+4 for n in [32, 63]

Personally, 2a is least surprising. 2b will result in an instruction in a disassembly that has both a different immediate and a different memory reference than the instruction I wrote, which would very much surprise me.

That said, I would tend to prefer this case simply generate a diagnostic saying the immediate is out of range for btl, perhaps with a fixit style notice to use btq or a btl w/ mem+4, but I can see the usability argument the other way. IIUC, a diagnostic is what that Solaris doc would get here since it uses an ‘l’ suffix by default.

Do you have a preference? From Linus’ description, the Linux kernel will always be in the (1) case due to their choice of constraint, so this is outside the scope of kernel expectations.

> Or even take the more general route discussed in the Intel manual
> bt $n, mem becomes btl $(n % 32), mem + 4*(n / 32)

This scares the crap out of me. :)

> bt, btr, and bts should probably operate in the same manner.

Agreed. Probably btc also? Any others?

> It seems unlikely people would ever write an immediate value outside the allowed range and want/expect the compiler to blindly copy the one byte immediate even though the hardware only looks at the least significant 4 (resp. 5 or 6) bits for btw (resp. btl or btq).

Also agreed. An out-of-range immediate is almost certainly either a) user error or b) user expecting the assembler to be clever. For a well-selected definition of a “reasonable range,” it’s probably safe to assume (b) and indeed be clever. Either [0,31] or [0,63] seem to fit the bill for that range.

-Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130715/ea34b968/attachment.html>