Displaying 20 results from an estimated 200 matches similar to: "[LLVMdev] JIT simple module and accessing the value fails"
2017 Jan 25
2
mcjit C interface problems
Hi, I'm attempting to use MCJIT with the C interface with llvm-3.9.0, and
it doesn't seem to work. This code is derived from Paul Smith's example
code:
int main(int argc, char const* argv[]) {
LLVMModuleRef mod = LLVMModuleCreateWithName("my_module");
LLVMTypeRef param_types[] = {LLVMInt32Type(), LLVMInt32Type()};
LLVMTypeRef ret_type =
2012 Apr 25
2
[LLVMdev] Crash in JIT
Hello,
[Using LLVM r155315, according to `svn log | head`]
I am experimenting with programatically building and jitting functions in a module, and I seem to be coming across a crash in some generated code. Using the llvm-c interface I build up the module which dumps like this:
; ModuleID = 'MyModule'
target datalayout = "i686-apple-darwin11"
target triple =
2012 Apr 25
0
[LLVMdev] Crash in JIT
Hi David,
I'm not certain, but to me the "LLVMSetTarget(module, "i686-apple-darwin11");" line looks suspicious. I'm not familiar with all the ins and outs of how target triples get handled, but it looks to me like that's requesting 32-bit code.
I think that if you omit that line completely then the target will be inferred from the execution environment. My best
2017 Jan 26
2
mcjit C interface problems
Thanks for the tip - getting closer:
$ ./capi_test 5 6
args[0]: 5
args[1]: 6
result: 4294959200
Here's the code I changed:
printf("args[0]: %d\n", (int)LLVMGenericValueToInt(args[0], 0));
printf("args[1]: %d\n", (int)LLVMGenericValueToInt(args[1], 0));
uint64_t (*func)();
func = (uint64_t (*)())LLVMGetFunctionAddress(engine, "sum");
2010 Aug 12
3
[LLVMdev] LLVM-C: Calling functions contained in other libraries
Hello,
I have a question concerning llvm-c.
I have set up a function that needs to invoke an external method, in a other library. It has the following signature: void* NSFullUserName(void);
The void* can be replaced with a i8*, that far I was able to get, but when my call is invoked, the engine gives me the following message:
LLVM ERROR: Tried to execute an unknown external function: i8* ()*
2010 Aug 12
0
[LLVMdev] LLVM-C: Calling functions contained in other libraries
On Aug 12, 2010, at 10:43 AM, F van der Meeren wrote:
> Where am I going wrong here?
>
Did you link against the library that contains the function?
-eric
2009 Nov 05
2
[LLVMdev] Strange error for libLLVMCore.a
mingw, llvm 2.6 (buid with llvm-gcc)
Example source code:
http://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html
I change
LLVMCreateJITCompiler(&engine, provider, &error);
to
LLVMCreateJITCompiler(&engine, provider, 3, &error);
$ llvm-gcc `llvm-config --cflags` -c fac.c
$ g++ `llvm-config --libs --cflags --ldflags core analysis
executionengine jit
2016 Aug 10
2
crash JIT with AVX intrinsics
Hi all,
I have some old code using the JIT via the LLVM-3.0-C API. I want to
upgrade to newer versions of LLVM. As a simple example I wrote a C program
that creates the following function and calls it:
; ModuleID = 'round-avx.bc'
target triple = "x86_64-pc-linux-gnu"
define void @round(<8 x float>*) {
_L1:
%1 = load <8 x float>* %0
%2 = call <8 x
2016 Jul 11
2
More function signatures for LLVMRunFunction?
Hello,
I am new to LLVM, and came across a snag when working through tutorials.
With the MC JIT execution engine, LLVMRunFunction only works on
"main()"-like functions -- other functions fail with the message
"Full-featured argument passing not supported yet!". The workaround
recommended by the tutorials is to create a main()-compatible wrapper
function and to send in
2010 Oct 25
0
[LLVMdev] Ocaml bindings for execution engines
Hi All,
Here is the code from bindings/ocam/executionengine/executionengine_ocaml.c.
/* llvalue -> GenericValue.t array -> ExecutionEngine.t -> GenericValue.t */
CAMLprim value llvm_ee_run_function(LLVMValueRef F, value Args,
LLVMExecutionEngineRef EE) {
unsigned NumArgs;
LLVMGenericValueRef Result, *GVArgs;
unsigned I;
NumArgs =
2008 Sep 12
1
[LLVMdev] [PATCH] Link in codegen components in llvm-c
This allows the use of shadow stack from the llvm-c API.
I am not sure this is the place to insert the include, though.
Index: include/llvm-c/ExecutionEngine.h
===================================================================
--- include/llvm-c/ExecutionEngine.h (revision 56175)
+++ include/llvm-c/ExecutionEngine.h (working copy)
@@ -24,6 +24,7 @@
#ifdef __cplusplus
extern "C" {
2008 Mar 04
1
[LLVMdev] [PATCH] Prefer to use *.opt ocaml executables as they are more efficient.
I noticed that the ocaml compilation isn't using the .opt
executables if they're available. We might gain a slight
optimization in ocaml compile time by optionally using them
with this patch.
---
autoconf/configure.ac | 18 +++++
configure | 195 ++++++++++++++++++++++++++++++++++++++++++------
2 files changed, 188 insertions(+), 25 deletions(-)
-------------- next part
2008 Mar 04
1
[LLVMdev] [PATCH] Cleanup the c and ocaml binding documentation.
---
bindings/ocaml/llvm/llvm.ml | 2 +-
bindings/ocaml/llvm/llvm.mli | 2 +-
bindings/ocaml/llvm/llvm_ocaml.c | 2 +-
include/llvm-c/Core.h | 32 +++++++++++++++++++-------------
4 files changed, 22 insertions(+), 16 deletions(-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 316a84e85ed2363551149e65a227c8e7c8192624.diff
Type:
2011 Oct 13
0
[LLVMdev] BasicBlock succ iterator
thank john,
i have used dump() , and each blocks had pred except entery block, i get the
following output:
fun main entry
entry:
%retval = alloca i32
%0 = alloca i32
%i = alloca i32
%j = alloca i32
%a = alloca [2 x i32]
%n = alloca i32
%t = alloca i32
%"alloca point" = bitcast i32 0 to i32
%1 = getelementptr inbounds [2 x i32]* %a, i32 0, i32 0
%2 = load i32*
2016 Jul 15
2
More function signatures for LLVMRunFunction?
Hi Lang,
Thanks for the reply. Responses below.
As far as I know nobody is actively working on MCJIT any more. I've been
> working on the next generation of LLVM JIT APIs (ORC - see
> include/llvm/ExecutionEngine/Orc) for a while now, but they don't have
> functionality for running arbitrary functions yet.
>
Thanks for the pointer to ORC -- it looks like the runFunction
2012 Mar 17
3
[LLVMdev] Python bindings in tree
At Fri, 16 Mar 2012 14:12:08 +0100,
Christoph Grenz wrote:
>
> Hello,
>
> Am Donnerstag, 15. März 2012, 21:15:02 schrieb Gregory Szorc:
> > There was some talk on IRC last week about desire for Python bindings to
> > LLVM's Object.h C interface. So, I coded up some and you can now find
> > some Python bindings in trunk at bindings/python. Currently, the
>
2017 Mar 09
2
LLVMGetBitcodeModuleInContext2 problem
Oops, missed initializing some stuff. Added:
LLVMLinkInMCJIT();
LLVMInitializeNativeTarget();
LLVMInitializeNativeAsmPrinter();
LLVMInitializeNativeAsmParser();
Now it crashes in LLVMGetFunctionAddress().
Hmm.
On Wed, Mar 8, 2017 at 5:14 PM, Toshiyasu Morita <toshi at tensyr.com> wrote:
> Made it a bit further. Here's the current code:
>
>
2012 Sep 27
0
[LLVMdev] Possible bug or misunderstanding of feature LLVMConstIntOfString
Hi All
I am a novice LLVM user trying to use LLVMConstIntOfString using the c api
to get a integer of arbitrary size from a hexadecimal string.
Example code follows:
LLVMContextRef context = LLVMContextCreate();
LLVMValueRef value =
LLVMConstIntOfString(LLVMInt64TypeInContext(context), "0x0000000f0000ffff",
16);
This is working properly as expected.
However I have noticed that
2014 Apr 04
2
[LLVMdev] Weird problems on calling an external function from MCJIT on Windows(mingw)
Hi,
I have a IR file generated by Clang:
; ModuleID = 'test_load_lib.c'
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f80:128:128-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32-S32"
target triple = "i686-pc-mingw32"
declare i32 @a_outside_func(i32)
define i32 @test_func() {
entry:
%call = call i32
2015 Mar 04
2
[LLVMdev] RFC: Better alternative to llvm.frameallocate for use in Windows EH
On Wed, Mar 4, 2015 at 12:36 AM, John McCall <rjmccall at apple.com> wrote:
> > On Mar 3, 2015, at 2:25 PM, Reid Kleckner <rnk at google.com> wrote:
> >
> > I realized that WinEH preparation can probably be a lot less invasive
> than it is currently.
> >
> > Initially, when I was thinking about recovering the address of an object
> in a parent stack