llvm dev - Jul 2013 - [LLVMdev] [BUG] Support unqualified btr, bts

Hi,

I happened to notice that linux.git uses plenty of btr and bts
instructions (not btrl, btrw, btsl, btsw).  For examples, see
arch/x86/include/asm/bitops.h.  LLVM barfs on these due to ambiguity,
while GNU as is fine with them.  Surely, there must be architectures
where the w/l variant is unavailable?  LLVM must support those
architectures, no?

Thanks.

On Wed, Jul 10, 2013 at 11:12 AM, Ramkumar Ramachandra
<artagnon at gmail.com> wrote:
> Hi,
>
> I happened to notice that linux.git uses plenty of btr and bts
> instructions (not btrl, btrw, btsl, btsw).  For examples, see
> arch/x86/include/asm/bitops.h.  LLVM barfs on these due to ambiguity,
> while GNU as is fine with them.  Surely, there must be architectures
> where the w/l variant is unavailable?
Both variants have existed since the Intel 386.

That said, we should probably handle this like GNU as because the
variants behave almost identically.  Please file a bug.

-Eli

On Wed, Jul 10, 2013 at 11:30:03AM -0700, Eli Friedman
wrote:
> On Wed, Jul 10, 2013 at 11:12 AM, Ramkumar Ramachandra
> <artagnon at gmail.com> wrote:
> > Hi,
> >
> > I happened to notice that linux.git uses plenty of btr and bts
> > instructions (not btrl, btrw, btsl, btsw).  For examples, see
> > arch/x86/include/asm/bitops.h.  LLVM barfs on these due to ambiguity,
> > while GNU as is fine with them.  Surely, there must be architectures
> > where the w/l variant is unavailable?
> 
> Both variants have existed since the Intel 386.
> 
> That said, we should probably handle this like GNU as because the
> variants behave almost identically.  Please file a bug.
I don't consider this a bug. Just like certain FP instructions, they
*are* ambigious and there is no reason to depend on magic assembler
choices.

Joerg