[LLVMdev] Getting To Native Code

[Reid Spencer]

Kewl Beans!  You're heading right where I need LLVM to go :) 

Details ...

On Wed, 2003-11-12 at 07:22, John Criswell wrote:

> 	Funny you should mention that; getting a C library compiled to LLVM 
> code is one of the tasks on my plate.	:)


Good. If I can help, please let me know.


> 	You are correct that the LLVM assembly language cannot accept native 
> assembly instructions or access machine specific features directly. 
> However, there is hope:
> 
> 	Long term, one of our projects is to port the Linux kernel to LLVM. 
> This project has the same problem that you have encountered; how to 
> access machine specific services.
> 
> 	Our current plan is to add a set of intrinsic functions that will give 
> us access to the hardware facilities that we need.  For example, we will 
> probably have an intrinsic that registers a function as a system call 
> handler, another intrinsic that performs I/O, another intrinsic that 
> tells us what hardware is connected to the machine, etc, etc.

I'd vote for just adding a new keyword, syscall, that works just like a
declare. For example:

syscall int "__mmap" (void* start, long length, int prot, int flags, int
fd, unsigned offset);

This would indicate that unlike a "declare" of the same form, calls to
mmap would invoke special
handling by placing arguments in registers and invoking a system trap ..
details left to the backend.

> 
> 	In this way, the actual hardware can be abstracted away so that LLVM 
> bytecode programs don't need to know about it.  All they see is a set of 
> intrinsic functions for the particular piece of hardware/OS upon which 
> they run.

A wonderful idea. Much of the code I've written is to abstract away the
operating system interface so
that XPL can be ported to many platforms. You're actually going one step
further and abstracting the
hardware.  This is totally cool!

> 
> 	Please note that the Linux kernel project is still in its infancy and 
> won't be done for awhile.	:)

Any ballpark ideas on when an alpha version could be available? Are we
talking months or years here?

> 
> 	In the meantime, there are still things you can do.  Please see below...
> 
> > 
> > What is the alternative? Write a library function in C and have it 
> > called by LLVM?
> 
> 	First, I should probably mention that an LLVM program has access to 
> just about all OS services offered to a regular native code program. 
> This is because undefined symbols in an LLVM program are resolved when 
> it is generated to native code.

Yes, I'd figured that out. Using just LLVIS you wouldn't be able to get
anything to run :)

> 
> 	Specifically, if you JIT a program using lli, the JIT looks the symbol 
> up in its own address space.  That is how LLVM programs find the system 
> calls and other library functions that are not compiled to LLVM bytecode.
> 
> 	For native code, the symbols are resolved at native code link time 
> (i.e. you run llc on the bytecode and then assemble it and link it).
> 
> 	For writing code that does special stuff (accesses machine registers, 
> etc), there are several alternatives:
> 
> 	1) As you suggested, you could write a library in C and compile it to 
> native code.  You would then be able to link this library with LLVM code 
> (either by loading it into the JIT with -load or by using llc to 
> generate native code and linking to your library).
> 
> 	2) You could add an intrinsic for it.  I'd only recommend this if it's 
> something that would be useful as a generic primitive; an intrinsic to 
> read performance registers would be okay; an intrinsic for creating 
> prime numbers would not.

Yes, keeping the set of intrinsics small and generally applicable to the
abstraction will be important. 
Unfortunately, however, there are several corner cases where the general
abstraction won't work. Machine
specific capabilities (array processors and hardware neural nets comes
to mind) would have to be accessed
directly. This is why LLVM needs an assembly pass through. No matter how
good the LLVM abstraction 
layer is at blending out differences in machine specific operations,
there will always be corner cases like
this that just don't lend themselves to abstraction.

I'd vote for an "asm" instruction that just passes literal text through
to the back end. Let the user ensure
its for the right hardware, etc.  For example:

asm "  movl    4(%esp), %eax
        andl    $0xffff, %eax
        rorw    $8, %ax
        ret"

The danger here is that the feature gets over used and subverts
optimization. Still, for the things that 
need it, it would be the right thing.


> 
> > 
> > The reason I'm asking is that I'd like as much code as possible to be 
> > open to optimization by LLVM. If the core of my runtime library can't be 
> > expressed in LLVM then it can't be optimized by it either.  Ideally, 
> > everything except the glue for system traps, interrupts and the like 
> > should be expressible in LLVIS.
> > 
> 
> 	That is where we are headed; we just have a way to go before we're there.
> 
> 	If you have any further questions, please feel free to ask.  I realize 
> I'm being pretty verbose here.


Sounds great.  Please keep me posted on progress and let me know if
there are things I can do
to help. This effort is in my best interest too.

Verbosity is a good thing!  Thanks for the explanation.


> 
> Regards,
> 
> -- John T.


Reid.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20031112/9b6061a4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20031112/9b6061a4/attachment.sig>