[polly] r244606 - Revise the simplification of regions

Tobias Grosser via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 11 23:47:14 PDT 2015


On 08/12/2015 01:12 AM, Michael Kruse wrote:
> Two corrections:
>
> First, such PHI nodes can only happen in the entry node, since
> buildPHIAccesses checks the origin of the incoming edges (not of the
> operands which I assumed). Sich PHI nodes can only appear in the entry
> node. So I think solutions 1 and 3 do work.
>
> Second, I now think it could not happen before my patch because if we
> are not in the case that polly.entering.block would not be create,
> SplitBlock in executeScopConditionally would have split the entering
> block s.t. the PHI blocks would be left in the entering block. To stop
> SplitEdge behave that way, it one must have one additional edge to the
> entering, either from the inside or outside of the region. If from
> inside, the PHI node must have a case for that block, making
> buildPHIAccesses it not ignore anymore. If from outside,
> simplifyRegion would have made a new entering block with the PHI
> nodes.
>
> This all doesn't look like designed deliberately. And it is what I
> meant with make simplifyRegion "stable" in D11867.
>
> I committed a test case for this (entry_with_trivial_phi.ll)

Hi Michael,

thank you for this detailed analysis. I played a little with what you
said and came up with the attached patch which I believe solves
the issue without introducing any special handling. What do you think?

Best,
Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Always-model-PHI-nodes-in-scop-if-not-in-same-nonaff.patch
Type: text/x-patch
Size: 4089 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150812/e56400f2/attachment.bin>


More information about the llvm-commits mailing list