[PATCH] D15693: [Polly] Take a PHI's incoming block as value user

Johannes Doerfert via llvm-commits llvm-commits at lists.llvm.org
Tue Dec 22 17:16:45 PST 2015


On 12/22, Michael Kruse wrote:
> Meinersbur added a comment.
> 
> In http://reviews.llvm.org/D15693#315190, @jdoerfert wrote:
> 
> > > Before this patch, we determine whether a value escapes the SCoP by checking whether it the instruction itself is within the scop. This is wrong for PHINodes because the value must be available in the incoming block instead of of where the PHI is.
> >
> >
> > I don't get it. A PHI (here Inst in the BlockGenerators) which is in the
> >  SCoP escapes the SCoP, if it is used outside the SCoP, or not? Where is
> >  the difference to any other instruction? Or do you talk about a user
> >  PHI? In that case I would say an instruction (here Inst) escapes the
> >  SCoP, if the user PHI is not in the SCoP. Either way the code we had
> >  seems fine to me but I could have missed something here...
> 
> 
> Yes, it is about the PHI as a user of a potentially escaping value (which by itself may or may not be defined by a PHI).
> 
> Think of the following case:
> 
>   scop_enter:
>     phi float [%v, %outofscop]
>     %v = ...
>   
>   scop_exit:
>   
>   outofscop:
>     br label %scop_enter
> 
> Is %v escaping? The answer is yes, because otherwise we'd need to add
> a MK_PHI WRITE to br label %scop_enter, which we cannot do because it
> is not a ScopStmt. Also see the comment in bool
> DominatorTree::dominates(const Instruction *Def, const Use &U). ("PHI
> nodes use their operands on edges")
The answer is no (maybe because your example is broken). If %v is in the
SCoP and __only__ used in the SCoP it does __not__ escape the SCoP.
Additionally, your patch changes the code generation not the modeling
(where MK_PHI writes would have been added).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151223/8870d3bf/attachment.sig>


More information about the llvm-commits mailing list