This is an archive of the discontinued LLVM Phabricator instance.

[Polly] Unique phi write accesses
ClosedPublic

Authored by Meinersbur on Dec 20 2015, 4:34 PM.

Details

Summary

Ensure that there is at most one phi write access per PHINode and ScopStmt. In particular, this would be possible for non-affine subregions with multiple exiting blocks. We replace multiple MAY_WRITE accesses by one MUST_WRITE access. The written value is constructed using a PHINode of all exiting blocks. The interpretation of the PHI WRITE's "accessed value" changed from the incoming value to the PHI like for PHI READs since there is no unique incoming value.

Because region simplification shuffles around PHI nodes -- particularly with exit node PHIs -- the PHINodes at analysis time does not always exist anymore in the code generation pass. We instead remember the incoming block/value pair in the MemoryAccess.

Diff Detail

Repository
rL LLVM

Event Timeline

Meinersbur updated this revision to Diff 43340.Dec 20 2015, 4:34 PM
Meinersbur retitled this revision from to [Polly] Unique phi write accesses.
Meinersbur updated this object.
Meinersbur added reviewers: jdoerfert, grosser.
Meinersbur added a project: Restricted Project.
Meinersbur added subscribers: llvm-commits, pollydev.
grosser accepted this revision.Dec 20 2015, 11:35 PM
grosser edited edge metadata.

Hi Michael,

this patch looks good to me. I only had two minor comments specific to this patch and one comment regarding all test case changes in this as well as the read/write uniqueing patches.

LGTM, assuming comments are addressed.

Best
Tobias

include/polly/ScopInfo.h
612 ↗(On Diff #43340)

reaching

lib/CodeGen/BlockGenerators.cpp
1248 ↗(On Diff #43340)

It might be worth to move the "Create a PHI of all possible outgoing values of this subregion" functionality into its own function.

test/Isl/CodeGen/non-affine-phi-node-expansion-2.ll
13 ↗(On Diff #43340)

It would be nice to convert this test case in an earlier commit to the 'CHECK-NEXT' style,
such that by removing the CHECK lines we actually know that the store won't be created any more. Some of the other test cases you modify already use the CHECK-NEXT style. For those just dropping the lines already ensures the lines never occur. If the CHECK-NEXT style would add a lot of code, you might want to add a CHECK-NOT line that verifies the store is not added any more. (Thought I prefer CHECK-NEXT style).

This comment holds for all test cases (where it applies) and possibly also for some of the earlier unique load/store patches.

20 ↗(On Diff #43340)

CHECK-NEXT?

test/Isl/CodeGen/non-affine-phi-node-expansion-3.ll
34 ↗(On Diff #43340)

CHECK-NEXT?

test/Isl/CodeGen/non-affine-phi-node-expansion-4.ll
38 ↗(On Diff #43340)

CHECK-NEXT?

test/ScopInfo/NonAffine/non_affine_loop_used_later.ll
42 ↗(On Diff #43340)

These test cases would also benefit from an (ahead-of-time) CHECK-NEXT conversion.

This revision is now accepted and ready to land.Dec 20 2015, 11:35 PM

Hi Michael,

this commit as well as D15510 and D15483 seem to be ready to commit after your isl-0.16.1 test-case reformatting has taken place. Did you just not get to this or does anything block these commits? I am asking as the more patches we keep in flight the more likely we will run into conflicts or cause conflicts with other (newer patches). So if something is OK to go, I would suggest to push it out as soon as possible. If something is blocking these commits, it would be interesting to understand what it is.

Best,
Tobias

D16522 was blocking this.

This revision was automatically updated to reflect the committed changes.