search for: ut_assert

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

Did you mean: i_assert
2011 Feb 01
0
[LLVMdev] Loop simplification
.../ Delete the terminator in the predecessor block pred->getTerminator()->eraseFromParent(); // Update predecessor PHIs for (BasicBlock::iterator it = pred->begin(); it != pred->end(); ++it) { PHINode *phi = dyn_cast<PHINode>(it); UT_ASSERT(phi); // Adjust the PHI to have the correct incoming block set for (pred_iterator pi = pred_begin(succ); pi != pred_end(succ); ++pi) { // We're a different predecessor than the predecessor block if (*pi != pred)...
2011 Feb 01
3
[LLVMdev] Loop simplification
On Feb 1, 2011, at 1:34 PM, Andrew Trick wrote: > On Feb 1, 2011, at 1:08 PM, Andrew Clinton wrote: > >> I have a (non-entry) basic block that contains only PHI nodes and an >> unconditional branch (that does not branch to itself). Is it always >> possible to merge this block with it's successor and produce a >> semantically equivalent program? I'm
2013 Nov 05
1
[LLVMdev] Thread-safe cloning
...eam stream(str); WriteBitcodeToFile(other.myModule, stream); StringRef ref(stream.str()); UT_ScopedPtr<MemoryBuffer> buf(MemoryBuffer::getMemBuffer(ref)); myModule = ParseBitcodeFile(buf.get(), myContext); UT_ASSERT(myModule); } On 06/18/2013 01:29 PM, Reid Kleckner wrote: > 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 >...
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