Wei Dang
2013-Mar-03 02:35 UTC
[LLVMdev] Question about method CodeExtractor::severSplitPHINodes
Thanks for reply Chuck. Please excuse me if I'm not supposed to reply to all. Are you saying all PHI nodes are required to include all its predecessor blocks no matter they have input or not? What about successor blocks? Are they optional if they don't provide inputs? BTW, where should I look at to verify this, the mem2reg.cpp & PromoteMemToReg.cpp? Thanks a lot. On Sat, Mar 2, 2013 at 6:39 PM, Caldarale, Charles R < Chuck.Caldarale at unisys.com> wrote:> > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > > On Behalf Of Wei Dang > > Subject: [LLVMdev] Question about method > CodeExtractor::severSplitPHINodes > > > In the implementation of serverSplitPHINodes(), why it only checks the > > first PHI node for possible multiple inputs from outside the region to > > extract. There could be more than one PHI nodes in the header block, > > and the code only checks the first one. I don't quite get it. What if > > the first PHI node contains only incoming values from inside the region, > > while subsequent PHI nodes have inputs from outside? Is that possible? > > No, it's not possible. All PHI nodes must include inputs for _all_ > predecessors of the block, so only one PHI node needs to checked for the > origins. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > 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/20130302/78fcdf5f/attachment.html>
Caldarale, Charles R
2013-Mar-03 05:14 UTC
[LLVMdev] Question about method CodeExtractor::severSplitPHINodes
> 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 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 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
2013-Mar-03 07:31 UTC
[LLVMdev] Question about method CodeExtractor::severSplitPHINodes
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 > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > 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>
Reasonably Related Threads
- [LLVMdev] Question about method CodeExtractor::severSplitPHINodes
- [LLVMdev] Question about method CodeExtractor::severSplitPHINodes
- [LLVMdev] Question about method CodeExtractor::severSplitPHINodes
- [LLVMdev] Problem in CodeExtractor::severSplitPHINodes()
- [LLVMdev] Problem in CodeExtractor::severSplitPHINodes()