search for: checklazyarguments

Displaying 5 results from an estimated 5 matches for "checklazyarguments".

2010 Jun 09
1
[LLVMdev] Segmentation fault 'cause of accessing function arguments
...ignalHandler(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 0x0000000100205686 (anonymous namespace)::CGPassManager::RunPassOnSCC(llvm::Pass*, l...
2013 Nov 05
1
[LLVMdev] Thread-safe cloning
...esting this approach (round tripping 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...
2010 Jun 09
0
[LLVMdev] Segmentation fault 'cause of accessing function arguments
...ignalHandler(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 0x0000000100205686 (anonymous namespace)::CGPassManager::RunPassOnSCC(llvm::Pass*, l...
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