search for: hammach

On 2/2/12 2:32 PM, Duncan Sands wrote: > On 02/02/12 14:25, Clemens Hammacher wrote: >> On 2/2/12 1:51 PM, Duncan Sands wrote: > ... >>> what do you mean by "copied over to the main module"? If you want to add >>> additional IR to the main module then you should link it in using the >>> linker. >> >> I think that th...

On 2/2/12 1:51 PM, Duncan Sands wrote: > On 02/02/12 13:30, Clemens Hammacher wrote: >> On 2/2/12 1:15 AM, Chris Lattner wrote: >>> I have to ask: why are you writing these modules out as separate bc files? >> >> I knew that someone would ask that ;) >> We need to have separate modules during runtime. One of them contains the code >>...

Hi Everyone, When I compile a program with clang with debug symbols enabled and I try to run it using the JIT (lli) I get the following error message. I am running on Lion (10.7.4). Thanks. George >> pseudo instructions should be removed before code emission UNREACHABLE executed at /Users/JD/Software/llvm3.1/llvm-3.1.src/lib/Target/X86/X86CodeEmitter.cpp:736! 0 lli

Hi Clemens, On 02/02/12 14:25, Clemens Hammacher wrote: > On 2/2/12 1:51 PM, Duncan Sands wrote: ... >> what do you mean by "copied over to the main module"? If you want to add >> additional IR to the main module then you should link it in using the linker. > > I think that the linker would indeed be able to remap...

On Tue, Mar 06, 2012 at 04:29:28PM +0100, Clemens Hammacher wrote: > I think a solution would be to always call a function through it's > stub, so that there is a single location to update when the function > is exchanged. This would mean that there is always exactly one level > of indirection, which is worse for programs that don't ex...

Dear all, I just stumbled over the following instruction in the LLVM IR of a C program compiled with clang: %26 = call i32 (...)* bitcast (i32 (i32, i32, i32, i32, i32)* @KeWaitForSingleObject to i32 (...)*)(i32 %23, i32 %24, i32 %25, i32 0, i32 0) Since our LLVM Parser choked on this instruction, I tried to check the documentation, but did not find anything about such nested bitcasts within

Hi Clemens, On 02/02/12 13:30, Clemens Hammacher wrote: > Hi Chris, > thanks for your answer! > > On 2/2/12 1:15 AM, Chris Lattner wrote: >> The linker has to solve the exact same problem (read multiple .bc files and >> unify types across them). This is the impetus behind TypeMapTy in >> lib/Linker/LinkModules.cpp....

...epted, that's why I am tending towards implementing it outside of LLVM. Why not? If they make LLVM better and aren't hacks, why wouldn't they be accepted? ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Clemens Hammacher [hammacher at cs.uni-saarland.de] Sent: 06 March 2012 16:39 To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Performance degradation when repeatedly exchanging JITted functions On 3/6/12 5:28 PM, Joerg Sonnenberger wrote: > Advantage of using the latest address: one saved jmp per call. Per...

Hi Chris, thanks for your answer! On 2/2/12 1:15 AM, Chris Lattner wrote: > The linker has to solve the exact same problem (read multiple .bc files and unify types across them). This is the impetus behind TypeMapTy in lib/Linker/LinkModules.cpp. You'll probably need to do something like that. I already looked into that. The linker is using the GlobalValues of both modules to identify

On 3/6/12 6:48 PM, James Molloy wrote: >> I don't think that a patch implementing any of those approaches would be >> accepted, that's why I am tending towards implementing it outside of LLVM. > > Why not? If they make LLVM better and aren't hacks, why wouldn't they be accepted? Okay, that motivated me to work on the patch again. I think I found a compromise of

On 3/6/12 5:28 PM, Joerg Sonnenberger wrote: > Advantage of using the latest address: one saved jmp per call. Per newly JITted call ;) > Advantage of using the initial address: easier G/C of intermediate > versions, less things to keep track of. I still think both versions require larger changes. When using the latest address, you have to keep track of all JITted functions per

Hi all, for a research project we need to repeatedly exchange functions in a program running in the JIT compiler. We currently do this by calling recompileAndRelinkFunction(), after changing the body of the function. Of course we synchronize enough to ensure that the JIT doesn't concurrently compile the function (which should only happen if lazy compilation is enabled). Now

Hi Clemens - thanks for your response. Clemens Hammacher wrote: > Hi Michael, > > since noone of the experts answered, let me share our experiences. We > recently had exactly the same problem, I posted on this list on January > 31st. > I didn't follow Duncans advice to "just use the linker", since for > several re...

Hi, I am using LLVM 3.1, and wants to print the machine code of JIT IR I try the following method EngineBuilder builder(&ctx.getModule()); builder.setEngineKind(EngineKind::JIT); * TargetMachine * tm = builder.selectTarget(); tm->Options.PrintMachineCode = true;* engine = builder.create(); and somewhere in my code, I use runJITonFunction(); Another question is that I am

Hi Chia Lun Liu, On 12/21/12 7:47 AM, ChiaLun wrote: > I am using LLVM 3.1, and wants to print the machine code of JIT IR > > I try the following method > > EngineBuilder builder(&ctx.getModule()); > builder.setEngineKind(EngineKind::JIT); > * > TargetMachine * tm = builder.selectTarget(); > tm->Options.PrintMachineCode = true;* > engine =

Hi Dong, try turning optimizations on. I get the select then: > └─[$]› echo 'int min(int a, int b) { return a < b ? a : b; }' | clang -xc -O1 -S -emit-llvm -o - - > ; ModuleID = '-' > target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128" >

hi Clemens Hammacher: thank you for your helpful answer. but i have another question about this 'select' instruction. i think that in LLVM IR, i can use a branch and two seperate assignments to replace 'select' instruction(am i right?). so is there any compiling option to aviod generate 'select...

On 2/27/12 8:27 PM, Michael Muller wrote: >>> 3) destructively convert all of the types in the imported module to our >>> existing types. >> >> That's what we actually implemented, following the idea I described in >> the mentioned post. We don't identify identical struct types by their >> name, since even in the new type system, names don't

...: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Joerg Sonnenberger Sent: 06 March 2012 15:45 To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Performance degradation when repeatedly exchanging JITted functions On Tue, Mar 06, 2012 at 04:29:28PM +0100, Clemens Hammacher wrote: > I think a solution would be to always call a function through it's > stub, so that there is a single location to update when the function > is exchanged. This would mean that there is always exactly one level > of indirection, which is worse for programs that don't ex...

On Jan 31, 2012, at 6:16 AM, Clemens Hammacher wrote: > This is because each module contains its own type table with all the types used in that module. When reading in the corresponding bitcode, the BitcodeReader explicitly calls StructType::create, without looking up in the context whether an equivalent type (even with the same name) alre...