[polly] r244606 - Revise the simplification of regions

[Michael Kruse via llvm-commits]

2015-08-12 9:38 GMT+02:00 Johannes Doerfert <doerfert at cs.uni-saarland.de>:
> On 08/12, Michael Kruse via llvm-commits 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).
> The operands are not the relevant part of the PHI semantics but the
> control flow is. There are examples for this in the PHI codegen
> discussion(s) we had on the list.

Can you provide I link? I won't be able to find it otherwise.


>> Sich PHI nodes can only appear in the entry
>> node. So I think solutions 1 and 3 do work.
> What is wrong with adding a pre SCoP block for all entry block PHI
> nodes? That solved the problem before and I cannot see the negative side
> effects and it needs only a minimal amount of code.

Its adding more code to get around issues in other places. Isn't it
better to reduce the overall complexity.

Anyhow, Tobias already committed a patch.


>> This all doesn't look like designed deliberately. And it is what I
>> meant with make simplifyRegion "stable" in D11867.
> In the original PHI codegen patch there was a detection of PHI nodes
> that were at some point part of the region (in the entry block) and
> split out of it by one of the region simplification methods just before
> the codegen part. Once detected these PHI's were deliberately ignored in
> the block codegen as they were no longer part of the region (SCoP).
>
> I cannot argue for the simplification and splitting stuff but the PHI
> codegen was aware of such PHI nodes and was handling them at some point.

Do you mean by that that it has been removed from the current codebase?


Michael