similar to: [LLVMdev] Creating a shared library from a module

Hi Frank, > I'd like to create a shared library out of a module in memory. Thus, I have > a working module and would like to produce a library similar to what That's not something LLVM can do on its own. You need a linker of some kind to create a shared library (to create appropriate GOT entries, resolve relocations, find dependent libraries, ...). LLVM includes a component called

Hi Tim, I am already using MCJIT. However, I am now confronted with architectures where it's not straight-forward to cross compile LLVM to (and use it's JIT'er). Thus, I am exploring the detour over a shared lib. Assuming that clang cooperates with the linker would it be sensible to track what path is taken when specifying -shared -fPIC? This should give me hints what is needed.?

Do you have a stack trace of the segfault? We have two different code emitters for X86 in LLVM. The one used by the normal compiler and MCJIT and the other used by the legacy JIT. All of the test cases for AVX support go through the first one so it gets the most attention. We try to keep the legacy JIT in sync with it, but have a history of failing at that. The stack trace of the segfault may

Is it possible that the AVX support in the JIT engine or x86-64 backend is not mature? I am getting segfaults when switching from a vector length 4 to 8 in my application. I isolated the barfing function and it still segfaults in the minimal setup: The IR attached implements the following simple function: void bar(int start, int end, int ignore , bool add , bool addme , float* out, float* in) {

It's not much. (gdb) bt #0 0x00007ffff7f6506b in ?? () #1 0x000000000045d01a in main () at main.cc:165 Line 165 is the call to the function that was compiled by the JIT'er. Meaning that JIT'ing the function went well, but the code or the pointer are somehow corrupt. There is no particular reason why I am working with the legacy interface. Would you recommend to use the MCJIT

It's not reproducible with 'opt'. I call the SLP pass from my application and only then the wrong IR gets generated. On the attached module I call via the function pass manager: 1) TargetLibraryInfo with the target triple 2) Set the data layout 3) Basic Alias Analysis 4) SLP vectorizer This produces the wrong IR. On the other hand running the attached module through 'opt

On 12 November 2013 16:05, Frank Winter <fwinter at jlab.org> wrote: > engineBuilder.setMCPU(llvm::sys::getHostCPUName()); > Try: engineBuilder.setMAttrs("-avx"); --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131112/4b00aed7/attachment.html>

> On Aug 7, 2014, at 2:57 PM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > > Your .ll file does not have a data layout. Opt will not initialize the DataLayoutPass. The SLP vectorizer will not vectorize because there is no DataLayoutPass. > > debug-cmake/bin/opt -default-data-layout="e-m:e-i64:64-f80:128-n8:16:32:64-S128" -basicaa -slp-vectorizer -S

I am having an issue with MCJIT on the ppc64 machine architecture. The symptom is that for a particular IR function the target machine won't emit neither an object nor an assembly file and subsequent calling the pointer to function results in a segfault. My application generates on the fly several functions with the builder and executes them with the MCJIT engine. I came across this

What would be needed in order to make MCJIT work on a new architecture? I am thinking BG/Q and Xeon Phi (native). Let's assume the components required for JIT (core, mcjit, native, etc.) can be cross-compiled and linked with an Intel or IBM compiler for such an architecture, and somehow one manages to execute the application. (I didn't try all that yet.) Also, let's assume there is

Right now, I am using TargetMachine::addPassesToEmitFile <http://llvm.org/docs/doxygen/html/classllvm_1_1LLVMTargetMachine.html#a356929c1f0d202e4a9d3202aff1dbb05> to write the output of a backend to a file. How can I tell LLVM to write into a memory buffer instead? -------------- next part -------------- An HTML attachment was scrubbed... URL:

MCJIT when lowering to x86-64 generates a MOVAPS (Move Aligned Packed Single-Precision Floating-Point Values) on a non-aligned memory address: movaps 88(%rdx), %xmm0 where %rdx comes in as a function argument with only natural alignment (float*). This x86 instruction requires the memory address to be 16 byte aligned which 88 plus something aligned to 4 byte isn't. Here the

Hello LLVM community, Over the last few years the LLVM team here at Apple and development teams elsewhere have been busily working on finding new and interesting uses for LLVM. Some of these uses are traditional compilers, but a growing number of them aren’t. Some of LLVM’s new clients, like WebKit, are embedding LLVM into existing applications. These embedded uses of LLVM have their own unique

On 11 November 2013 01:36, Frank Winter <fwinter at jlab.org> wrote: > There is no particular reason why I am working with the legacy > interface. Would you recommend to use the MCJIT interface in general? > Absolutely! Bugs found in MCJIT are far more likely to get fixed. The aim is to deprecate the old JIT as soon as possible, so solving problems in it don't get priority.

Filip Pizlo wrote: > This is exciting! > > I would be happy to help. > > >> On Aug 5, 2014, at 12:38 PM, Chris Bieneman<beanz at apple.com> wrote: >> >> Hello LLVM community, >> >> Over the last few years the LLVM team here at Apple and development teams elsewhere have been busily working on finding new and interesting uses for LLVM. Some of

> (7) Make the C API truly great. > > I think it’s harmful to LLVM in the long run if external embedders use the C++ API. I think that one way of ensuring that they don’t have an excuse to do it is to flesh out some things: > > - Add more tests of the C API to ensure that people don’t break it accidentally and to give more gravitas to the C API backwards compatibility claims. >

On 12 November 2013 21:10, Josh Klontz <josh.klontz at gmail.com> wrote: > Porting my project from JIT to MCJIT did not fix the code generation bug > Frank is also experiencing. However, Renato's "-avx" suggestion did resolve > the issue for me. Hopefully we can get some traction on this bug, happy to > help where possible! > Hi Josh, Frank, Glad to see you

On Tue, Aug 5, 2014 at 2:49 PM, Filip Pizlo <fpizlo at apple.com> wrote: > >> On Aug 5, 2014, at 1:46 PM, Eric Christopher <echristo at gmail.com> wrote: >> >>> (7) Make the C API truly great. >>> >>> I think it’s harmful to LLVM in the long run if external embedders use the C++ API. I think that one way of ensuring that they don’t have an

I'm working on adding source-based profiling support for MCJIT and in the process of implementing this, I came across a test case where an object is being generated that wants to have relocations applied to the .debug_line section. I see in the DebugInfo code that it currently only supports relocations applied to either the .debug_info or the .debug_info.dwo section. Can anyone give me an

That relocation handling is only done for the llvm-dwarfdump binary. MCJIT handles relocations a bit different. I think you just need to go ahead and allow the MCJIT relocation handling machinery to work on non-alloc sections and it should go ahead and handle these just fine, unless you're using the existing stuff in lib/DebugInfo to print out information or something? If this isn't what