[PATCH v2] X86: disambiguate unqualified btr, bts

[Tim Northover]

Hi,

> If llvm's policy is to reject all ambiguous
> instructions, then 824a907 (and possibly other commits) must be
> reverted for a consistency.

I think there's actually a fairly strong argument for that. I'd prefer
it to more ambiguous instructions personally. Tricky though because it
may mean code that compiled with LLVM before doesn't now, which isn't
something we want in general.

In fact, what would people think if I do send such a patch? Does
compatibility override correctness here? Or am I missing some reason
bt is special too?

> If the instructions really are Wrong, why hasn't
> linux.git been patched yet?

Well, that one's easy enough. Linux has been a GCC-built project since
forever. Patches to support other toolchains just aren't a priority.

> What is the problem with matching gas behavior?

The problem is that behaviour seems to violate the intended design of
AT&T mnemonics. Why should these bit-testing instructions be special?
If we make btr default to btrl, shouldn't we do the same for every
other pair?

I think the most likely scenario is that gas had an implementation bug
that people started making use of and by the time they found out there
wasn't much they could do.

> Can you write me a coherent explanation
> as to why it is Wrong to support perfectly valid instruction
> mnemonics,

That's begging the question.

> and how linux.git should be patched, in that case?

By changing all instances of bts and btr to the appropriate
unambiguous mnemonic (always the "l" version, if you're correct about
gas's behaviour and GCC doesn't mind).

Cheers.

Tim.