Displaying 10 results from an estimated 10 matches for "myexecutionengin".
Did you mean:
myexecutionengine
2012 Nov 25
2
[LLVMdev] MCJIT and Lazy Function Creators
Out of curiosity, I'm replacing the JIT with MCJIT on my compiler. As
all "external" functions are provided by the language's FFI mechanism,
it does
MyExecutionEngine->DisableSymbolSearching();
MyExecutionEngine->InstallLazyFunctionCreator(&MyLazyFunctionCreator);
which works fine with the JIT. However, MCJIT insists on resolving
unknown symbols by searching them outdoors and seems oblivious of the
existence of MyLazyFunctionCreator.
Is this a bug?...
2012 Nov 27
0
[LLVMdev] MCJIT and Lazy Function Creators
Óscar Fuentes <ofv at wanadoo.es> writes:
> Out of curiosity, I'm replacing the JIT with MCJIT on my compiler. As
> all "external" functions are provided by the language's FFI mechanism,
> it does
>
> MyExecutionEngine->DisableSymbolSearching();
> MyExecutionEngine->InstallLazyFunctionCreator(&MyLazyFunctionCreator);
>
> which works fine with the JIT. However, MCJIT insists on resolving
> unknown symbols by searching them outdoors and seems oblivious of the
> existence of MyLazyFunctionC...
2012 Nov 27
2
[LLVMdev] MCJIT and Lazy Function Creators
...Subject: Re: [LLVMdev] MCJIT and Lazy Function Creators
Óscar Fuentes <ofv at wanadoo.es> writes:
> Out of curiosity, I'm replacing the JIT with MCJIT on my compiler. As
> all "external" functions are provided by the language's FFI mechanism,
> it does
>
> MyExecutionEngine->DisableSymbolSearching();
> MyExecutionEngine->InstallLazyFunctionCreator(&MyLazyFunctionCreator);
>
> which works fine with the JIT. However, MCJIT insists on resolving
> unknown symbols by searching them outdoors and seems oblivious of the
> existence of MyLazyFunctio...
2010 May 13
0
[LLVMdev] Handling of thread_local globals by llc -march=cpp
Hello
> I've been exploring thread local globals in llvm and as part of this investigation I ran llc -march=cpp over a trivial llvm bc file which uses thread local storage for a global. For some reason llc -march=cpp seems to ignore the thread_local and produce code to create a standard global. Is this expected behaviour, a known limitation, or otherwise?
Thanks for the report. Should be
2010 May 13
2
[LLVMdev] Handling of thread_local globals by llc -march=cpp
...IntegerType::get(getGlobalContext(), 32), false, GlobalValue::ExternalLinkage, 0, "global", 0, true);
in order to create a thread local global variable instead of a standard global variable causes the function (which uses the global) produced by the following line of code:
void *FPtr = MyExecutionEngine->getPointerToFunction(MyFunction);
to segfault when I call it in the following sequence of code:
int (*FP)() = (int (*)())FPtr;
int res = FP();
when the function executes correctly in the case of instead having created a standard global variable.
Doh!
As far as I got with this was to note...
2012 Jun 17
1
[LLVMdev] Adding code after compilation
Hi,
I want to be able add a function to a module after it is (partly) compiled in JIT. Let's say we have these functions:
Foo()
{
Stuff;
}
Bar()
{
Foo();
MoreStuff;
}
I want to have a module with Foo optimized and have a callable pointer to Foo. Later, I want to generate Bar, optimize it (so Foo is inlined) and than get a callable pointer to Bar.
Is this possible?
If so, is there a way to
2013 Jan 20
1
[LLVMdev] Get the value of a GlobalVariable
Hi,
I am executing a C program using JIT. When the program exits, the control
comes back to my program which initiates the JIT. Now, I want to read
the value(not the LLVM nomenclature) of a global variable (not the LLVM
nomenclature). I am able to get the global variable, using the following
command:
GlobalVariable *my_global = Mod->getNamedGlobal("MY_GLOBAL");
I want to know the
2010 May 13
0
[LLVMdev] Handling of thread_local globals by llc -march=cpp
I note also that this is not a currently unsupported target case where an error should/could/would be produced on attempting to emit code with thread local references. I say this because clang is able to compile both c source with __thread on a global and bc containing a @variable = thread_local global ... and a function that references the thread local global variable to both assembly and machine
2010 May 13
3
[LLVMdev] Handling of thread_local globals by llc -march=cpp
target triple = "i386-pc-linux-gnu"
On 13/05/2010, at 9:25 PM, Anton Korobeynikov wrote:
>> int (*FP)() = (int (*)())FPtr;
>> int res = FP();
>>
>> when the function executes correctly in the case of instead having created a standard global variable.
> What is the platform you're running the code on?
>
> --
> With best regards, Anton
2010 May 13
2
[LLVMdev] Handling of thread_local globals by llc -march=cpp
Hi all,
I've been exploring thread local globals in llvm and as part of this investigation I ran llc -march=cpp over a trivial llvm bc file which uses thread local storage for a global. For some reason llc -march=cpp seems to ignore the thread_local and produce code to create a standard global. Is this expected behaviour, a known limitation, or otherwise?
Thanks in advance.
Details are as