[LLVMdev] Question about method CodeExtractor::severSplitPHINodes

Wei Dang jacdang at gmail.com
Sat Mar 2 23:31:12 PST 2013

I appreciate the explanation Chuck. I guess I know where I got it wrong,
I thought phi node only considers incoming edges where there is a value
flowing in.
I guess the truth is that any phi node should consider all incoming edges
whether or not
there is an incoming value (or a 'real' defined incoming value)
For those edges without a real defined value, phi nodes just put undef as
their value for that edge.
Am I right? This makes a lot sense now.

On Sat, Mar 2, 2013 at 10:14 PM, Caldarale, Charles R <
Chuck.Caldarale at unisys.com> wrote:

> > From: Wei Dang [mailto:jacdang at gmail.com]
> > Subject: Re: [LLVMdev] Question about method
> CodeExtractor::severSplitPHINodes
> > Please excuse me if I'm not supposed to reply to all.
> You should do reply-all, to make sure the list sees all of the thread.
> > Are you saying all PHI nodes are required to include all its predecessor
> blocks
> > no matter they have input or not?
> That's the way SSA works - each input to a block must be provided by all
> paths leading to the block.  That must be from each immediate predecessor
> or from a common predecessor of two or more immediate predecessors that do
> not mutate the value.
> > What about successor blocks? Are they optional if they don't provide
> inputs?
> The question doesn't make sense; we're only concerned with the
> predecessors here.  If you have a loop, some successor (possibly the block
> of interest) is also a predecessor and must conform to SSA usage.
> > where should I look at to verify this, the mem2reg.cpp &
> PromoteMemToReg.cpp?
> It's an inherent characteristic of SSA:
> http://en.wikipedia.org/wiki/Static_single_assignment_form
> (or any of numerous textbooks and papers).
>  - Chuck
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail and
> its attachments from all computers.

Wei Dang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130303/cfedf71e/attachment.html>

More information about the llvm-dev mailing list