Suppose I wanted to, say, write glibc for LLVM (fat chance! :) I would need at some point to write (hopefully a small amount) of native code to, say, access specific registers, handle interrupts, or generate operating system traps. From my (somewhat cursory) review of AsmParser, it seems like this can't be done with LLVM right now. There is nothing in AsmParser or the rest of LLVM that would allow native assembly instructions to be passed through to the back end. Is my finding correct or can this be done currently with LLVM in some way I haven't found? What is the alternative? Write a library function in C and have it called by LLVM? 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20031112/1598eada/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/1598eada/attachment.sig>
Reid Spencer wrote:> Suppose I wanted to, say, write glibc for LLVM (fat chance! :) I would > need at some point to write (hopefully a small amount) of native code > to, say, access specific registers, handle interrupts, or generate > operating system traps.Funny you should mention that; getting a C library compiled to LLVM code is one of the tasks on my plate. :)> > From my (somewhat cursory) review of AsmParser, it seems like this > can't be done with LLVM right now. There is nothing in AsmParser or the > rest of LLVM that would allow native assembly instructions to be passed > through to the back end. > > Is my finding correct or can this be done currently with LLVM in some > way I haven't found?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. 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. Please note that the Linux kernel project is still in its infancy and won't be done for awhile. :) 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. 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.> > 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. Regards, -- John T. -- ********************************************************************* * John T. Criswell Email: criswell at uiuc.edu * * Research Programmer * * University of Illinois at Urbana-Champaign * * * * "It's today!" said Piglet. "My favorite day," said Pooh. * *********************************************************************
> From my (somewhat cursory) review of AsmParser, it seems like this can't > be done with LLVM right now. There is nothing in AsmParser or the rest > of LLVM that would allow native assembly instructions to be passed > through to the back end.Correct.> Is my finding correct or can this be done currently with LLVM in some > way I haven't found?Nope you're right. Adding to what John said, eventually we will support GCC style 'asm' blocks, but these will only have extremely limited (if any) support in the JIT. If you need low-level machine specific functionality now, probably the best way to do it is to write a .s file or a .c file with asm's in it, and compile that with a native compiler. Since we are ABI compatible, you shouldn't have any problem linking it to llvm compiled programs. -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/
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>