similar to: [LLVMdev] [RFC] Splitting init.trampoline into init.trampoline and adjust.trampoline

Hi Sanjoy, > Attached set of patches splits llvm.init.trampoline into an "init" > phase and an "adjust" phase, as discussed on the "Go on dragonegg" > thread. thanks for doing this. The patches look good, though the decomposition into individual patches is not that great (since things won't always work, in fact not even compile I think, with not all

Hi! Attached patches split init.trampoline into adjust.trampoline and init.trampoline, like in gcc. As mentioned in the previous mail, I've not made a documentation patch, since I'm not sure about what the documented semantics of llvm.adjust.trampoline should be. Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was

Hi Sanjoy, the first and last patches look good (except that you didn't add any tests for the auto-upgrade functionality). Comments on the other two below. > Attached patches split init.trampoline into adjust.trampoline and > init.trampoline, like in gcc. > > As mentioned in the previous mail, I've not made a documentation > patch, since I'm not sure about what the

Hi, I would like to implement an auto-redial function in a context. The idea is about like this: Dial a number Hear busy Hangup Pick up again Dial a code like *123 => jumps into a context which redials until callresult is not busy Maybe like this: [autoredial] exten => s,1,Set(number=${CHANNEL(lastdialed)}) exten => s,2,Dial(SIP/${number}@account,60,g) exten => s,3,Wait(15) exten

Fellow developers, I'm parallelizing loops to be called by pthread. The thread body that I pass to pthread_create looks like define i8* @loop1({ i32*, i32* }* nest %parent_frame, i8* %arg) parent_frame is pointer to shared variables in original function 0x00007f0de11c41f0: mov (%r10),%rax 0x00007f0de11c41f3: cmpl $0x63,(%rax) 0x00007f0de11c41f6: jg 0x7f0de11c420c

Hi! I noticed in the LegalizeDAG.cpp (SelectionDAGLegalize::LegalizeOp): case ISD::INIT_TRAMPOLINE: case ISD::FRAMEADDR: case ISD::RETURNADDR: // These operations lie about being legal: when they claim to be legal, // they should actually be custom-lowered. Action = TLI.getOperationAction(Node->getOpcode(), Node->getValueType(0)); if (Action == TargetLowering::Legal)

Attached patches change how dragonegg lowers trampolines (for compatibility with Go). -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-the-trampolines-for-Go.patch Type: text/x-diff Size: 5108 bytes Desc: not available URL:

Hi, > I'm parallelizing loops to be called by pthread. The thread body that I pass > to pthread_create looks like > > define i8* @loop1({ i32*, i32* }* nest %parent_frame, i8* %arg) > parent_frame is pointer to shared variables in original function > > 0x00007f0de11c41f0: mov (%r10),%rax > 0x00007f0de11c41f3: cmpl $0x63,(%rax) > 0x00007f0de11c41f6:

Hi! It seems I forgot to attach the patch that documentations the two new intrinsics. I've attached it here. Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Documentation.patch Type: text/x-diff Size: 5722 bytes Desc: not available URL:

Hi! Thank you for the detailed review. I've attached a new set of patches. -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-New-trampoline-intrinsics-for-LLVM.patch Type: text/x-diff Size: 16783 bytes Desc: not available URL:

The address of the callee may be more than 2 GB away in memory, which cannot be encoded as an immediate offset in the call instruction. So, the value is first materialized with a mov instruction which can encode the immediate and then jumped to through a register. Reid On Tue, Feb 22, 2011 at 12:03 PM, Xin Tong Utoronto <x.tong at utoronto.ca> wrote: > I have a question on the LLVM JIT

I have a question on the LLVM JIT I did some brief memory reading one day and I found that a call to a non-library function is resolved by the X86CompilationCallback, but the X86CompilationCallback is reached through a trampoline. why can not the generated code jump to the X86CompilationCallback function directly ? 0x2b0a6a4d103b: mov $0x2b0a6a561010,%rax 0x2b0a6a4d1045:

I understand that we need to push the address to a register then branch using the register. But i am asking why there is a trampoline there such that a call to foo is first branched to an snippet and the snippet branches to the X86CompilationCallback. is this snippet necessary ? Thanks Xin On Tue, Feb 22, 2011 at 12:39 PM, Reid Kleckner <reid.kleckner at gmail.com>wrote: > The

For lowering llvm.memcpy.* etc SelectionDAG::getMemcpy generates a libcall to "memcpy" as a last resort. See the code snippets below. // FIXME: pass in DebugLoc std::pair<SDValue,SDValue> CallResult = TLI.LowerCallTo(Chain, Type::VoidTy, false, false, false, false, 0, CallingConv::C, false, getExternalSymbol("memcpy",

On some machines, the location at 0x40e does not point to the beginning of the EBDA. Rather, it points to the beginning of the BIOS-reserved area of the EBDA, while the option ROMs place their data below that segment. For this reason, 0x413 is actually a better source than 0x40e to get the location of the real-mode trampoline. But it is even better to fetch the information from the multiboot

Hi Sanjoy, > Attached patches change how dragonegg lowers trampolines (for > compatibility with Go). I think the right approach is to add an llvm.adjust.trampoline intrinsic to LLVM (and change llvm.init.trampoline to not return a result). Then the dragonegg trampoline code will become trivial, and the Go problem will just Go away :) In fact this was how I first did it: two intrinsics,

I'm not sure whether there are any other cases where using LLVM requires knowledge of the target architecture, but needing it for trampolines is worrying me. I'm putting together things where the program that's generating the LLVM intermediate code doesn't have any way to know what the target architecture will be. Right now I'm using alloca to get a block that is expected

Duncan Sands wrote: > is it important for you to have portable bitcode (i.e. the trampoline > size as some kind of symbolic constant, maybe via a global or an > intrinsic) that works on all targets or would it be enough to have the > LLVM info for the target expose the trampoline size, so when generating > IR for a target X you would query the method for target X and if it

Eli Friedman wrote: > I didn't say we wouldn't accept a patch. It's just that up until now > nobody has particularly cared because trampolines aren't used very > much. Fair enough. If I get to the point where I understand how to implement it cleanly, I'll submit a patch. Best regards, Eric

Eli Friedman wrote: > Also, for lack of an intrinsic, there's a relatively easy workaround: > you can declare a global containing the correct size, then link in a > small target-specific .bc with the definition right before code > generation. So why can't LLVM provide that global? I don't care whether it's a global, intrinsic, or whatever. If I have to provide