similar to: [LLVMdev] llvm header fixes

I have a function in llvm ir as follows: def [2 x [3 x double]] @fun() { return [ ... ]; // a [2 x [3 x double]] constant } I would like to JIT this function in C. I first get the void pointer using: void *FPtr = TheExecutionEngine->getPointerToFunction( func ); Then I need to conver this void pointer to the corresponding C function pointer type, and then call the function

On Mon, Aug 6, 2012 at 9:35 AM, Peng Cheng <gm4cheng at gmail.com> wrote: > I have a function in llvm ir as follows: > > def [2 x [3 x double]] @fun() > { > return [ ... ]; // a [2 x [3 x double]] constant > } > > I would like to JIT this function in C. > > I first get the void pointer using: > > void *FPtr =

Does anyone know what is the complexity of the "mem2erg" optimization on llvm ir? Is it linear or quadratic? Regards, -Peng -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150817/c3b210f1/attachment.html>

According to http://llvm.org/docs/CMake.html, "Shared libraries are not supported on Windows and not recommended in the other OSes". The problem is that static libraries have some limitations, especially when linked into multiple shared libraries, the global data of llvm could have multiple copies leading to undefined behaviors. This has caused much pains during my usage of llvm. My

Bug is reported with test cases. see http://llvm.org/bugs/show_bug.cgi?id=15124 . Thanks, -Peng On Wed, Jan 30, 2013 at 12:14 PM, Anton Korobeynikov < anton at korobeynikov.info> wrote: > > Has anyone seen this problem before? and is there any fix or work around > > for that? > Please provide a testcase and fill LLVM problem report into bugzilla. > > Thanks! >

Hi Peng, Can you please open a bugzilla and attache the LL file ? Can you please reproduce it on ToT ? Thanks, Nadav On Feb 7, 2013, at 9:08 PM, Peng Cheng <gm4cheng at gmail.com> wrote: > I have an llvm ir, which generates the following machine code using llc (llvm 3.0 on win32) after # *** IR Dump After X86 DAG->DAG Instruction Selection ***: > > The first three lines

Hi, I am using llvm to generate jit code for numerical computation on window 7 64 platform. There is a function call, pow, in the jit code. The problem is that at run time, the pow function call sometimes links to msvcrt.dll, and sometimes to msvcr100.dll. These two calls from two dlls return different results, causing sporadic results. I tried to make the pow function either intrinsic or

I have an llvm ir, which generates the following machine code using llc (llvm 3.0 on win32) after # *** IR Dump After X86 DAG->DAG Instruction Selection ***: The first three lines and the last two lines alone together are used to compute "sin" for some double number. - line 1: move the stack pointer down 8 - line 2: copy the updated stack pointer to a base register - line 3: copy a

Hi, I have an ir at the end of this email. Run it with: llc -mcpu=i386 -march=x86-64 -mattr=-sse2 and get assertion below. Changing cpu does not help. I am using llc from the latest svn repository. Any suggestions to work around this? I need to disable sse2 instructions for x86-64. Thanks, -Peng -----error message------ llc: X86FloatingPoint.cpp:332: unsigned int getFPReg(const

I came in to an email this morning that said basically the same thing for the reduced example we were looking at. However, the original IR it came from (before hand reduction) had the data layout set correctly, so there's probably still *something* going on. It's just not what I thought at first. :) Philip On 09/10/2014 02:26 AM, Roel Jordans wrote: > Looking at the -debug

On Fri, Mar 27, 2009 at 3:48 PM, Evan Cheng <evan.cheng at apple.com> wrote: > Run with -debug-only=jit. OT: I take it the recommended model for tools that embed LLVM is for them to accept all of LLVM's command line arguments on their own command lines? For Python, it'd be much nicer to make this stuff tweakable through a module at runtime, or even, for thread-safety reasons, as

Hi Evan, Thanks for the pointers. We found a simple test case that causes the problem (thanks to Tom in my group): #include<stdio.h> #include<stdlib.h> void test(); void (*funcPtr)(); int main(int argc, char **argv) { funcPtr = test; test(); } void test() { if(funcPtr == test) { printf("OK!\n"); } else { fprintf(stderr, "Bad!\n"); exit(1);

I've filed PR3043 for this. Evan On Nov 3, 2008, at 4:00 PM, Prakash Prabhu wrote: > Hi Evan, > > Thanks for the pointers. We found a simple test case that causes the > problem (thanks to Tom in my group): > > #include<stdio.h> > #include<stdlib.h> > > void test(); > void (*funcPtr)(); > > int main(int argc, char **argv) { > funcPtr =

On Fri, Mar 27, 2009 at 2:25 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > On Fri, Mar 27, 2009 at 3:48 PM, Evan Cheng <evan.cheng at apple.com> wrote: >> Run with -debug-only=jit. > > OT: I take it the recommended model for tools that embed LLVM is for > them to accept all of LLVM's command line arguments on their own > command lines? Well, sort of...

I have the following simplified llvm ir, which basically returns value based on the first value of a constant array. ---- ; ModuleID = 'simple_ir3.txt' @f.b = constant [1 x i32] [i32 1], align 4 ; constant array with value 1 at the first element define void @f(i32* nocapture %l0) { entry: %fc_ = alloca [1 x i32] %f.b.v = load [1 x i32]* @f.b store [1 x i32] %f.b.v, [1 x

Maybe I should say b2 should be eliminated. Since b1 and b2 are same type and b1 is not used any more after the function call, b2 can be replaced by b1. This will save an alloca. In my test, if the function is not external, b1 is eliminated. But with external function, it did not. Since the ir is generated, I cannot manually update b2 with b1. I would like the optim pass do it. On

Here is an llvm ir of a module. It seems that "b1" should be eliminated by dead store elimination. But it did not. Could anyone explain why and how "b1" can be eliminated? Thanks, -Peng %0 = type { [3 x [1 x i32]] } declare %0 @external_fcn3(i32, i32, i32, i32, [3 x [1 x i32]]*) define i32 @f3(i32 %a) readnone { entry: %b1 = alloca [3 x [1 x i32]] %b2 = alloca [3 x

Hi Zoltan, The part that determines whether SIB byte is needed caused a lot of regressions last night (see Geryon-X86-64 etc.). I've reverted it for now. Please take a look. Thanks, Evan On May 4, 2009, at 3:49 PM, Evan Cheng wrote: > Committed as revision 70929. Thanks. > > Evan > > On May 3, 2009, at 8:29 PM, vargaz wrote: > >> >> Hi, >> >>

Hi, I recently ran into a case, where x86 fails to run correctly. Checking into the emitted code, it seems that the local memory anchored at ebp has conflict with stack memory anchored at esp prepared for function calls. For example, let us say: foo() { ... call bar(); } There is some local data for foo() at ebp-170h. while preparing the call to bar, some data is written to esp+17h. The

I have been toying around with the LLVM tutorial code and I am trying to deduce what I can from it as a basis for a compiler frontend for a simple language of my own devising (once I understand what I am doing I will probably attempt mapping a more complex language target). I am having some difficulties however understanding how certain things work and I was hoping perhaps someone could help me