Displaying 20 results from an estimated 3000 matches similar to: "thread safety ExecutionEngine::getFunctionAddress"
2016 Dec 20
0
thread safety ExecutionEngine::getFunctionAddress
> On Dec 20, 2016, at 9:13 AM, koffie drinker via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> Hi,
>
> I'm trying to speed up the JIT time with llvm (3.9.1).
> So far i've implemented the object cache, used FastISel and disabled optimizations.
I can’t help with the rest, but just wanted to mention that totally disabling the IR optimizations is not necessarily
2016 Dec 22
0
thread safety ExecutionEngine::getFunctionAddress
So I've made code to invoke the getfunctionaddress() in parallel. I did
verify that the code was good, by substituting getfunctionaddress() with a
bunch bogus computations.
It seems that the code with getfunctionaddress() is being serialized. Is
there a giant lock somewhere per executionengine?
I have one execution engine that holds all the modules. Going through the
llvm-dev list archives,
2016 Aug 12
2
Reducing JIT time
Hi,
What other options do I have to reduce JIT time for large amount of code?
- setting optimization level to none helps a lot
- enabling FastISel doesn't seem to help much
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160812/f05d51fb/attachment.html>
2016 Jul 07
2
ObjectCache and getFunctionAddress issue
Hi all,
I'm trying to add pre-compiled object cache to my run-time.
I've implemented the object cache as follow:
class EngineObjectCache : public llvm::ObjectCache {
private:
std::unordered_map<std::string, std::unique_ptr<llvm::MemoryBuffer>>
CachedObjs;
public:
virtual void notifyObjectCompiled(const llvm::Module *M,
llvm::MemoryBufferRef Obj) {
auto id =
2016 Feb 26
2
Heap problems with 3.8.0rc2 in combination with vs2015 sp1
Turns out llvm initializes memory before the constructor is invoked. Visual
studio has /sdl by default on, and the __autoclassinit2 will zero the
memory before the constructor is reached causing all the setters to be
default zero. which clears the hashungoff var and causing the delete to
flow in wrong part.
When /sdl is enabled, the compiler generates code to perform these checks
at run time:
—
2016 Feb 25
0
Heap problems with 3.8.0rc2 in combination with vs2015 sp1
I found the root cause, but I don't know what's the best approach to fix it.
Under windows, 64 bit, when a function is created the void *User::operator
new(size_t Size) operator allocates space + Use*.
In the Use* the HasHungOffUses is set to true. So the ptr to the use* is
returned as new object. This ptr is NOT the ptr that was allocated by the
system. For that ptr you need ptr - word
2016 Feb 25
2
Heap problems with 3.8.0rc2 in combination with vs2015 sp1
I made the llvm::Function() constructor public (for testing purpose) and
used the non-overloaded new.
auto func = ::new llvm::Function(...)
if (func) func->eraseFromParent();
And the heap corruption is gone! Did something changed in llvm::User::new
between 3.7.1 and 3.8.0 ?
I found a bug in llvm ?
On Thu, Feb 25, 2016 at 12:10 PM, koffie drinker <gekkekoe at gmail.com> wrote:
> I
2016 Oct 28
4
MCJit and remove module memory leak?
I'm on llvm 3.8.1 and was wondering if there's a memory leak in the
removeModule impl of mcjit.
In the tutorial http://llvm.org/releases/3.8.1/docs/tutorial/LangImpl4.html
a module is removed from the Jit by invoking removeModule.
According to the tutorial:
"Its API is very simple:: addModule adds an LLVM IR module to the JIT,
making its functions available for execution;
2016 Nov 16
2
MCJit and remove module memory leak?
Hi Kevin, Koffie,
We will start migrating to ORC for next release, but for now, this release
> invoke delete after remove right?
MCJIT's removeModule method does not delete the module. You'll need to do
that manually. OrcMCJITReplacement is a bug-for-bug compatible
implementation of MCJIT using ORC components, so it does not free the
memory either.
Does this mean MCJIT is
2016 Jul 29
2
Memory usage with MCJit
Hi Koffie,
I'd highly recommend switching to ORC from MCJIT. It is much more flexible
when it comes to memory-management.
1. I took the approach of 1 execution engine with multiple modules (I'm not
> removing modules once they have been added). During profiling, I noticed
> that the memory usage is high with a lot of code. How can I reduce the
> memory usage? Is one execution
2016 Feb 24
2
Heap problems with 3.8.0rc2 in combination with vs2015 sp1
I recently upgraded from llvm 3.7.1 to a pre release of llvm (3.8.0rc2) in
order to test some issues regarding bug 24233.
After upgrading I starting to see heap corruption messages in vs 2015 sp1
when my program exits.
"HEAP[ConsoleEngine.exe]: Invalid address specified to RtlValidateHeap(
0000000000290000, 0000000000318698 )"
Initially I only got it in Release build. Debug build seems
2016 Feb 25
0
Heap problems with 3.8.0rc2 in combination with vs2015 sp1
I downloaded 3.8.0rc3 and I also have it in 3.8.0rc3.
I did set a data access breakpoint on the first function ptr that causes
the invalid heap. This would allow me to break whenever someone is touching
that address. It did not show double deletes during debugging. Further more
I managed to narrow it down to 2 function calls:
// stupid code, but its just for triggering heap error
auto func =
2017 Jul 27
2
llvm 5.0 release rc1 : ExecutionEngine fatal error on MCJIT::getFunctionAddress
Hi everyone,
In llvm 4.0 the MCJIT::getFunctionAddress function return 0 (a null
address) when the symbol is not found :
*uint64_t MCJIT::getSymbolAddress(const std::string &Name, bool
CheckFunctionsOnly) { std::string MangledName; { raw_string_ostream
MangledNameStream(MangledName);
Mangler::getNameWithPrefix(MangledNameStream, Name, getDataLayout()); }
return
2013 Oct 21
0
[LLVMdev] An enhancement for MCJIT::getFunctionAddress
I should have read this before sending my previous reply. :-)
I'm not a big fan of default parameters, but some form of what you are suggesting may be useful. See my other comments on this topic in the other reply.
-Andy
From: Yaron Keren [mailto:yaron.keren at gmail.com]
Sent: Saturday, October 19, 2013 3:17 PM
To: Kaylor, Andrew; <llvmdev at cs.uiuc.edu>
Subject: An enhancement
2013 Oct 19
2
[LLVMdev] An enhancement for MCJIT::getFunctionAddress
In MCJIT, the old JIT functions are deprecated in favor
of getFunctionAddress.
Code like:
llvm::Function *F = M->getFunction(FuncName);
void *FN = EE->getPointerToFunction(F);
should be rewritten as
uint64_t FN = EE->getFunctionAddress(FuncName);
While functionally identical, in case the correct module is known the new
version will be much slower, linear with the number of added
2013 Oct 21
0
[LLVMdev] An enhancement for MCJIT::getFunctionAddress
There's probably a lot that we could do, but I can't think of anything easy.
Basically every time we need to look up a symbol by name we're going to each module and saying "Do you have this symbol?" It would likely be much better if we grabbed the function names from the module and did the search ourselves so that we could keep some information about the things that
2013 Oct 21
2
[LLVMdev] An enhancement for MCJIT::getFunctionAddress
The search is linear? If that’s really true, we should fix that.
On Oct 21, 2013, at 10:14 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote:
> I should have read this before sending my previous reply. :-)
>
> I’m not a big fan of default parameters, but some form of what you are suggesting may be useful. See my other comments on this topic in the other reply.
>
>
2016 Mar 02
3
What is the status of clang++ and LLVM on Windows
Hi,
I am wondering what the status of Clang++ and LLVM on the Windows platform ?
When I last saw what the state was there was not proper linking and
more recently heard that the Structured Exception Handling was not
working.
The status page seems somewhat out of date ?
Many thanks in advance,
Aaron
2013 Oct 22
2
[LLVMdev] An enhancement for MCJIT::getFunctionAddress
I don’t follow. Why are we looking at the module at all? That query should work even (especially) after the Module is deleted. We should be able to have a local symbol table that’s a DenseMap or something similar to resolve from names to target addresses. That map would be updated as part of the compilation when the object’s symbol table gets read.
-Jim
On Oct 21, 2013, at 4:55 PM, Kaylor,
2013 Oct 22
0
[LLVMdev] An enhancement for MCJIT::getFunctionAddress
Hi Jim,
Clearly searching for name should not be linear in modules but with a map
of some kind.
After compilation to IR each module has a StringMap symbol table.
After compiling to MC and loading the object file, the dynamic linker has
a StringMap symbol table for all loaded modules.
In the usual use case you'll load module(s) into MCJIT and then compile /
link them and all is well, no