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

[Ramkumar Ramachandra]

[Please be friendly towards non-subscribers and always reply-to-all; I
found your message in the list archives]

Joerg Sonnenberger wrote:
> > 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.
>
> There is no way to tell from the arguments whether bts should be btsw or
> btsl. That's the ambiguity it is complaining about. Fixing it is
> trivial. There are other cases with similar issues in the 8087 syntax
> with size of the floating point operand.

I see.  Can you explain the results of this experiment to me?

Input #1:
  btrw	$1, 0
  btr	$1, 0
  btsw	$1, 0
  bts	$1, 0

Output #1 from gas:
   1 0000 660FBA34      btrw    $1, 0
   1      25000000
   1      0001
   2 000a 0FBA3425      btr     $1, 0
   2      00000000
   2      01
   3 0013 660FBA2C      btsw    $1, 0
   3      25000000
   3      0001
   4 001d 0FBA2C25      bts     $1, 0
   4      00000000
   4      01

Input #2:
  btrl	$1, 0
  btr	$1, 0
  btsl	$1, 0
  bts	$1, 0

Output #2 from gas:
   1 0000 0FBA3425      btrl    $1, 0
   1      00000000
   1      01
   2 0009 0FBA3425      btr     $1, 0
   2      00000000
   2      01
   3 0012 0FBA2C25      btsl    $1, 0
   3      00000000
   3      01
   4 001b 0FBA2C25      bts     $1, 0
   4      00000000
   4      01
   5

bts{w} is defined as: ins i16mem:$src1, i16i8imm:$src2
while bts{l} is defined as: ins i32mem:$src1, i32i8imm:$src2

My disambiguation of bts is defined as: def : InstAlias<"btr $imm,
$mem", (BTR32mi8 i32mem:$mem, i32i8imm:$imm)>;

ie. I treat the first operand is an i32mem, and the second is as
i32i8imm, to disambiguate bts to btsl; exactly like bt disambiguates
to btl in the previous line (from 824a907):

def : InstAlias<"bt $imm, $mem", (BT32mi8 i32mem:$mem, i32i8imm:$imm)>;

What am I missing?

> On Thu, Jul 11, 2013 at 10:59:32AM +0530, Ramkumar Ramachandra wrote:
> > 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.
>
> That's a very, very weak argument. There are a lot of things Clang
> rejects as errors by default that has been used in old code bases,
> because GCC accepted it.

That was a personal opinion, and I've consistently demonstrated that I
have no experience/ in-depth knowledge of assemblers.  I'm not sure
what to do myself, but this disambiguation seems to be the reasonable
(not claiming Correct or Incorrect) solution.  My agenda is simple: I
don't like the outdated cruft that GNU as is, and I think a lot of
codebases can benefit from the transition to LLVM's assembler.  That's
not going to happen by sitting around doing nothing.