[LLVMdev] Inline Assembly

[Chris Lattner]

On Mon, 13 Sep 2004, John Criswell wrote:

> Actually, there should be a way around it.  I'm currently working on
> extensions to LLVM for operating system support.  You wouldn't be able
> to take the stock i386 Linux kernel and compile it, but you could write
> an operating system that would be completely compilable by LLVM (once I
> finish, that is).

Being able to use intrinsics is definitely good, but it's not sufficient.
There will always be things we don't cover, and inline asm will be
required.  In any case, compiling programs off the shelf certainly does
require inline asm support, so we do need it regardless of what intrinsics
we have.

> The difficult part is the code of the OS that changes native hardware
> state.  The kernel's code for changing the program counter to execute a
> signal handler, or the code in fork() that sets up the new process to
> return zero when it begins running for the first time: these are the
> hard parts, because native i386 state is visible in LLVM programs (more
> accurately; for our research, we don't want it visibile).

Some things really do want to be written in inline asm, and those things
are obviously non-portable.  This is not a problem, the goal of LLVM isn't
to turn every non-portable program into a portable one :)

> The bigger problem is GCC.  GCC provides extended inline asm stuff that
> will probably be painful to pass from GCC to LLVM (and Linux, BTW, uses
> this feature a lot).

Actually, the inline asm support provided by GCC is quite well thought out
and makes a lot of sense (inline asms are required to define their side
effects in target-independent terms).  The big complaint that I have is
it's incredibly baroque syntax.  Eventually we should also support other
forms of inline asm by translating them into the LLVM inline asm format,
but keeping the inline asm format symantically equivalent to the GCC
format is basically what we want.

> My impression is that inline assembly bites us a lot not because it's
> used a lot but because the LLVM compiler enables #defines for the i386
> platform that we don't support.

We should aspire to be as compatible with GCC as reasonable, and including
inline asm support is a big piece of that.

In terms of implementation, adding inline asm support is just a "small
matter of implementation": it shouldn't cause any fundamental problems
with the llvm design.  In particular, LLVM should get an "asm"
Instruction, which takes a blob of text and some arguments.  The big
missing feature in LLVM is multiple return value support, which is
required by asms that define multiple registers.  My notes on multiple ret
values are here if anyone is interested:
http://nondot.org/sabre/LLVMNotes/MultipleReturnValues.txt

-Chris

-- 
http://llvm.org/
http://nondot.org/sabre/