Displaying 5 results from an estimated 5 matches for "getincomingvalueforblock".
2011 Feb 01
0
[LLVMdev] Loop simplification
...ccessor PHIs
for (BasicBlock::iterator it = succ->begin();
succ->getFirstNonPHI() != it; ++it)
{
PHINode *phi = dyn_cast<PHINode>(it);
UT_ASSERT(phi);
UT_ASSERT(phi->getBasicBlockIndex(pred) >= 0);
Value *val = phi->getIncomingValueForBlock(pred);
PHINode *predphi = dyn_cast<PHINode>(val);
if (predphi && predphi->getParent() != pred)
predphi = 0;
phi->removeIncomingValue(pred, false);
for (pred_iterator pi = pred_begin(pred);
pi != pred_end(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
2004 Feb 05
0
[LLVMdev] Re: phi nodes
...mportant LLVM design kind of material.
On Thu, 5 Feb 2004, Michael Kahl wrote:
> I note that in your representation of phi nodes, you key the incoming
> value to the incoming block. Both appear explicitly (in pairs) in the
> operand list. There is even a method
> "llvm::PHINode::getIncomingValueForBlock" which performs this
> computation.
yup.
> There are several potential problems with this approach, so I wonder how
> you have addressed them. The most significant issue is that this
> representation works only if all of the predecessor blocks are unique.
> (Otherwise, the in...
2004 Dec 07
1
[LLVMdev] Question adding dummy basic blocks
Hi,
I got a problem when I am trying to add a dummy basic block.
Let say there are two blocks, A and B.
A----->B
I am trying to generate new BB called C which is located between A and B, but not break the edge of AB. The graph is like the following
A---->B
\ /
\ /
C
There is new BB 'C' with edges AC and CB.
It is kind of like what breakcriticaledge pass does.
2020 Mar 18
2
valid BasicAA behavior?
Am Di., 17. März 2020 um 16:56 Uhr schrieb Chawla, Pankaj via llvm-dev
<llvm-dev at lists.llvm.org>:
> All I am expecting from DA is a direction vector containing (*).
There seems to be a bug in DI, see Felipe's answer.
> I think the main problem is that currently there is no exact way DA can query AliasAnalysis in a ‘conservatively correct’ manner.
>
> Using UnknownSize