BGB wrote:> > for x86: > I presume LLVM supports inline assembler, and also uses the traditional > frame pointer-based stack layout, but I don't know the details (people who > know LLVM could probably be more helpful here). > > ok, maybe here is an option: > after getting the value (in the created stub), execute a chunk of inline > assembler to modify the caller (note: will probably need to modify inline > asm syntax, as compilers tend to differ on this point...). > >Thanks BGB, but at this point I can handle it ;-). The problem is not how in theory (patch the caller), but how in the LLVM code generation process. There are three steps for that: 1) How to represent the stub in the IR? An intrinsic? An external field with a ghost linkage? 2) At which point in LLVM do we know we won't have any optimization, so that the field operation is next to the stub call? 3) Make LLVM think the stub call is not a real call, so that callee-saved registers do not get clobbered.> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
On Wed, 7 Nov 2007, Nicolas Geoffray wrote:> Thanks BGB, but at this point I can handle it ;-). The problem is not > how in theory (patch the caller), but how in the LLVM code generation > process. There are three steps for that: > > 1) How to represent the stub in the IR? An intrinsic? An external field > with a ghost linkage?Probably an intrinsic. The trick is making it general purpose, not language specific.> 2) At which point in LLVM do we know we won't have any optimization, so > that the field operation is next to the stub call?You'll probably want to do this late in the code generator.> 3) Make LLVM think the stub call is not a real call, so that > callee-saved registers do not get clobbered.LLVM supports calling convetions like "coldcc". The idea of coldcc is that the function is compiled to not clobber callee-save registers. However, in practice, no current code generators do anything special with it, it's compiled like fastcc or ccc. -Chris -- http://nondot.org/sabre/ http://llvm.org/
Hi Chris, Chris Lattner wrote:> On Wed, 7 Nov 2007, Nicolas Geoffray wrote: > >> Thanks BGB, but at this point I can handle it ;-). The problem is not >> how in theory (patch the caller), but how in the LLVM code generation >> process. There are three steps for that: >> >> 1) How to represent the stub in the IR? An intrinsic? An external field >> with a ghost linkage? >> > > Probably an intrinsic. The trick is making it general purpose, not > language specific. > >I'm not sure actually how can I do that language specific ;). OK currently only Java does that (from what I know), but intrinsics like getElementDouble or setElementDouble do look general purpose. Unless, I'm too Java-minded?>> 2) At which point in LLVM do we know we won't have any optimization, so >> that the field operation is next to the stub call? >> > > You'll probably want to do this late in the code generator. >Therefore when instructions are lowered to target-specific instructions?> >> 3) Make LLVM think the stub call is not a real call, so that >> callee-saved registers do not get clobbered. >> > > LLVM supports calling convetions like "coldcc". The idea of coldcc is > that the function is compiled to not clobber callee-save registers. > However, in practice, no current code generators do anything special with > it, it's compiled like fastcc or ccc. > >As long as there is room for it, and obviously coldcc is here for that, it works fine for me :) Thanks, Nicolas> -Chris > >