Displaying 5 results from an estimated 5 matches for "haslazyarguments".
2010 Jun 09
1
[LLVMdev] Segmentation fault 'cause of accessing function arguments
...0000000100426a32 PrintStackTrace(void*) + 38
1 opt 0x0000000100426e8c SignalHandler(int) + 254
2 libSystem.B.dylib 0x00007fff82a9880a _sigtramp + 26
3 LLVMRCI.dylib 0x000000010148e6ae (anonymous namespace)::RCI::ID + 16462
4 opt 0x0000000100010e89 llvm::Function::hasLazyArguments() const + 21
5 opt 0x00000001000114e3 llvm::Function::CheckLazyArguments() const + 21
6 opt 0x000000010013a421 llvm::Function::arg_begin() + 21
7 LLVMRCI.dylib 0x0000000101483e02 (anonymous namespace)::RCI::runOnSCC(llvm::CallGraphSCC&) + 184
8 opt...
2013 Nov 05
1
[LLVMdev] Thread-safe cloning
...through bitcode in memory) and it works
beautifully - and isn't that much slower than cloning.
I have noticed however that the copy process isn't thread-safe. The
problem is that in Function, there is lazy initialization code for
arguments:
void CheckLazyArguments() const {
if (hasLazyArguments())
BuildLazyArguments();
}
void BuildLazyArguments() const;
I've worked around this by calling Function::getArgumentList() outside
the threaded code to harden it before the threaded copies. Are there
other lazy data structures that need to be solidified before threading?
Shou...
2010 Jun 09
0
[LLVMdev] Segmentation fault 'cause of accessing function arguments
...0000000100426a32 PrintStackTrace(void*) + 38
1 opt 0x0000000100426e8c SignalHandler(int) + 254
2 libSystem.B.dylib 0x00007fff82a9880a _sigtramp + 26
3 LLVMRCI.dylib 0x000000010148e6ae (anonymous namespace)::RCI::ID + 16462
4 opt 0x0000000100010e89 llvm::Function::hasLazyArguments() const + 21
5 opt 0x00000001000114e3 llvm::Function::CheckLazyArguments() const + 21
6 opt 0x000000010013a421 llvm::Function::arg_begin() + 21
7 LLVMRCI.dylib 0x0000000101483e02 (anonymous namespace)::RCI::runOnSCC(llvm::CallGraphSCC&) + 184
8 opt...
2013 Jun 18
0
[LLVMdev] Thread-safe cloning
You could probably round trip it through bitcode in memory. I think all of
the IR cloning functionality assumes that only one context is being used.
Even if the serialization isn't efficient as a clone could be, it should
give you very high confidence that everything Just Works. :)
On Tue, Jun 18, 2013 at 1:16 PM, Andrew Clinton <andrew at sidefx.com> wrote:
> I have a
2013 Jun 18
2
[LLVMdev] Thread-safe cloning
I have a Module/LLVMContext that I'd like to clone and manipulate in
different threads (each thread may perform different translation /
optimization, so they need unique copies). Currently this process has
to be locked, since each clone of the Module still refers to the same
LLVMContext. Is there a way to clone both the Module and LLVMContext so
that the copies can be manipulated