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

[Ramkumar Ramachandra]

Jim Grosbach wrote:
> That does raise a clarifying question here. Is the code you’re interested in
> using Intel or AT&T syntax?
>
> Also note that the question isn’t whether we should support the btr/bts
> instructions. We absolutely must (and do). The question is whether we are
> properly handling the un-suffixed mnemonic form of the assembly syntax.
>
> Perhaps you can help by clarifying via explicit example what code you
> believe should work but does that. Descriptions are great, but specifics are
> better once we’re this deep into the details.

I don't know!  This is the first time I'm hearing about differences
between Intel and AT&T syntax; I have absolutely no clue how btr/bts
_should_ be implemented, and the only specifics I have are real-world
examples: linux.git/gas.  Does looking at bitops.h in the kernel tree
help?

For the record, I don't think matching linux.git/gas is a problem:
they're very authoritative pieces of software that have been around
for a _really_ long time.  What matters to me is that real-world
software works as expected, even if it violates some transcendental
(but unimplemented) authoritative standard [1].  If other mainstream
assemblers handle btr/bts differently, I would see a cause for worry;
otherwise, no.

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.

Not sure I understand this.

[1]: Especially considering that we can't seem to find one.