search for: nhowel

.... Presumably the jobs are running long enough that compiling and linking them is negligible. The only downsides of using a .so are that you have to load the library from the filesystem and you have to indirect globals through the GOT/PLT. Reid On Fri, Mar 26, 2010 at 5:16 PM, Howell, Nathan <nhowell at ebay.com> wrote: > If you really trying to avoid linking everything into a shared library > (easiest choice), consider splitting up the compilation into a few more > steps: > > > > 1) Compile and optimize once as part of your build, target LLVM bitcode > instead of ma...

...y jit. * Allocate your JIT code within 2GB of your text segment. * Find a way to look up the external function with dlsym or maybe the ExecutionEngine's LazyFunctionCreator instead of addGlobalMapping. * Upgrade to the top of the svn tree. On Mon, Dec 7, 2009 at 10:01 AM, Howell, Nathan <nhowell at ebay.com> wrote: > I have an external function that was added with > ExecutionEngine::addGlobalMapping... and the JIT is burning the wrong > address into the emitted function. All of the addresses have > 0xffffff8d00000000 added to them. Does this look familiar to anyone? I'm...

...ot using the JIT so I don't know if those fixes applies in our case. As far as using PIC goes, the ELFCodeEmitter has asserts to tell you that PIC isn't currently supported. Will have to get the 2.7 update and try it out. Thanks. -----Original Message----- From: Howell, Nathan [mailto:nhowell at ebay.com] Sent: Thursday, June 17, 2010 3:45 PM To: Eli Friedman; Smith, Tim Cc: llvmdev at cs.uiuc.edu Subject: RE: [LLVMdev] Relocation issue with jump tables in ELF object files on X86_64 I had this problem a while back and received this response from Jeffrey. FWIW this is fixed in 2.7 by...

I have an external function that was added with ExecutionEngine::addGlobalMapping... and the JIT is burning the wrong address into the emitted function. All of the addresses have 0xffffff8d00000000 added to them. Does this look familiar to anyone? I'm using 2.6 on Solaris10/x64 if it matters. This has been working for about two months and I can't readily figure out what I changed to break

I had this problem a while back and received this response from Jeffrey. FWIW this is fixed in 2.7 by defaulting to CodeModel::Large and using indirect (far) calls. -----Original Message----- From: Jeffrey Yasskin [mailto:jyasskin at google.com] Sent: Monday, December 07, 2009 11:32 AM To: Howell, Nathan Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] 2.6 JIT using wrong address for

If you really trying to avoid linking everything into a shared library (easiest choice), consider splitting up the compilation into a few more steps: 1) Compile and optimize once as part of your build, target LLVM bitcode instead of machine code 2) Ship .bc files out to each node 3) Fix-up call instructions in a BasicBlockPass, run JIT without any/many additional IR optimizations enabled This

Hi Reid. Thanks for your response. We will be running this code in different processes across different nodes. Basically we have thousands of "executor" processes that are solely responsible for executing this code generated at compile-time across partitioned data. Rather than each one of these processes invoking the jit and compiling with full opts and all of that, we believe it may

It looks like llvm::DisableScheduling is not defined anywhere but it still lives on in TargetOptions.h... I've attached a hugely complicated patch for 2.7 to remove it. thanks, -n -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100316/769e4161/attachment.html> -------------- next part --------------

Are there any known issues with the ResolvedUndefsIn in 2.7? We've hit this particular stack a couple times now in the JIT. I've copied the failing bitcode to disk and doesn't crash opt or llc. It doesn't repro easily in the JIT either, but the stack is always the same... hoping it's a known issue. Thanks! TerminatorInst *TI = BB->getTerminator(); >>>>if