similar to: [LLVMdev] [PATCH] x86/asm: avoid mnemonics without type suffix

(resent without HTML) On 07/14/2013 05:56 AM, Ramkumar Ramachandra wrote: > 1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30) > changed a bunch of btrl/btsl instructions to btr/bts, with the following > justification: > > The inline assembly for the bit operations has been changed to remove > explicit sizing hints on the instructions, so the assembler will

On 07/14/2013 12:23 PM, Jeremy Fitzhardinge wrote: > (resent without HTML) > > On 07/14/2013 05:56 AM, Ramkumar Ramachandra wrote: >> 1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30) >> changed a bunch of btrl/btsl instructions to btr/bts, with the following >> justification: >> >> The inline assembly for the bit operations has been

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. The Intel documentation implies that this is the case: > If the bit base operand specifies a memory location, it represents the address of the byte in memory that contains the bit base (bit 0 of the specified byte) of the bit string (see Figure

On Sun, Jul 14, 2013 at 5:56 AM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > 1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30) > changed a bunch of btrl/btsl instructions to btr/bts, with the following > justification: > > The inline assembly for the bit operations has been changed to remove > explicit sizing hints on the instructions, so the

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.

Stephen Checkoway wrote: > [...] Thanks for the absolutely splendid analysis! > For the memory, immediate form without the suffix, it seems like the options are > 1. If the immediate value is in [0,15], use btsl/btrl since it saves a byte, otherwise error; > 2. Follow both gas's behavior and the Solaris assembler manual Jim Grosbach linked to which stated that unsuffixed

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

On Wed, Jul 10, 2013 at 7:15 PM, Jim Grosbach <grosbach at apple.com> wrote: > > On Jul 10, 2013, at 6:54 PM, Stephen Checkoway <s at pahtak.org> wrote: > > On Jul 10, 2013, at 17:44, Jim Grosbach <grosbach at apple.com> wrote: > > The length specifier is, as I understand it, required when the instruction > references memory but is optional (and inferred from

On Wednesday 10 July 2013 22:18:23 Jevin Sweval wrote: > http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/arch/x86/include/ > asm/bitops.h#L68 > > Here is one example that I found. Are the inline assembly arguments > ambiguous in size? It would help us for sure to build the kernel and others. -- JS

On Jul 10, 2013, at 6:54 PM, Stephen Checkoway <s at pahtak.org> wrote: > On Jul 10, 2013, at 17:44, Jim Grosbach <grosbach at apple.com> wrote: >> The length specifier is, as I understand it, required when the instruction references memory but is optional (and inferred from the registers) for the register variants. >> >> The best reference I know of for the

Linus Torvalds wrote: >> btrl $1, 0 >> btr $1, 0 >> btsl $1, 0 >> bts $1, 0 > > What the heck is that supposed to show? I was trying to show a reduced case where gas doesn't complain, but llvm-mc does. Try compiling this with llvm-mc, and you'll get: .text btrl $1, 0 in.s:2:1: error: ambiguous instructions require an

On Jul 10, 2013, at 2:30 PM, Eric Christopher <echristo at gmail.com> wrote: > On Wed, Jul 10, 2013 at 2:08 PM, Ramkumar Ramachandra > <artagnon at gmail.com> wrote: >> Jim Grosbach wrote: >>> To say that another way, is the assembler correctly diagnosing a previously >>> unnoticed problem in the project source code, or is the assembler not >>>

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

Jim Grosbach wrote: > To say that another way, is the assembler correctly diagnosing a previously > unnoticed problem in the project source code, or is the assembler not > behaving correctly according the the documented Intel assembly mnemonics? Where are the authoritative instruction set pages? If such a thing were readily available, why are there gaps in the current implementation? A

On Wed, Jul 10, 2013 at 12:29 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > The instructions btr and bts are perfectly valid, and have existed since > Intel 386. GNU as supports them fine. Unfortunately, LLVM does not > support them, and barfs with: > > error: ambiguous instructions require an explicit suffix > > Fix this problem by disambiguating it

Hi Andrew, This series of patches lays the basic ground work for the paravirtualized kernel patches coming later on. I think this lot is ready for the rough-and-tumble world of the -mm tree. The main change from the last posting is that all the page-table related patches have been moved out, and will be posted separately. Also, the off-by-one in reserving the top of address space has been

Hi Andrew, This series of patches lays the basic ground work for the paravirtualized kernel patches coming later on. I think this lot is ready for the rough-and-tumble world of the -mm tree. The main change from the last posting is that all the page-table related patches have been moved out, and will be posted separately. Also, the off-by-one in reserving the top of address space has been

On Wed, Jul 10, 2013 at 2:08 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > Jim Grosbach wrote: >> To say that another way, is the assembler correctly diagnosing a previously >> unnoticed problem in the project source code, or is the assembler not >> behaving correctly according the the documented Intel assembly mnemonics? > > Where are the authoritative

Jim Grosbach wrote: > Also, please elaborate on why this is a good change. Because gas accepts it > isn’t sufficient reason in and of itself. That they're valid instructions isn't sufficient reason? Should I additionally say that linux.git uses them? I wrote: > The instructions btr and bts are perfectly valid, and have existed since > Intel 386.

On Jul 10, 2013, at 1:44 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > Jim Grosbach wrote: >> Also, please elaborate on why this is a good change. Because gas accepts it >> isn’t sufficient reason in and of itself. > > That they're valid instructions isn't sufficient reason? Should I > additionally say that linux.git uses them? > Is the