diff options
| author | Michael Kruse <llvm@meinersbur.de> | 2017-09-21 19:08:23 +0000 |
|---|---|---|
| committer | Michael Kruse <llvm@meinersbur.de> | 2017-09-21 19:08:23 +0000 |
| commit | bfca5f433476e54433ec7e0b05a6310b4e0d4692 (patch) | |
| tree | 2caaba139208beb36c92519ef110a334cfea346a /polly/lib/Transform | |
| parent | 0dde08c3cbee9314e5cdc24d5295f1d98663a99f (diff) | |
| download | bcm5719-llvm-bfca5f433476e54433ec7e0b05a6310b4e0d4692.tar.gz bcm5719-llvm-bfca5f433476e54433ec7e0b05a6310b4e0d4692.zip | |
[DeLICM] Allow non-injective PHIRead->PHIWrite mapping.
Remove an assertion that tests the injectivity of the
PHIRead -> PHIWrite relation. That is, allow a single PHI write to be
used by multiple PHI reads. This may happen due to some statements
containing the PHI write not having the statement instances that would
overwrite the previous incoming value due to (assumed/invalid) contexts.
This result in that PHI write is mapped to multiple targets which is not
supported. Codegen will select one one of the targets using
getAddressFunction(). However, the runtime check should protect us from
this case ever being executed.
We therefore allow injective PHI relations. Additional calculations to
detect/santitize this case would probably not be worth the compuational
effort.
This fixes llvm.org/PR34485
llvm-svn: 313902
Diffstat (limited to 'polly/lib/Transform')
| -rw-r--r-- | polly/lib/Transform/DeLICM.cpp | 14 |
1 files changed, 13 insertions, 1 deletions
diff --git a/polly/lib/Transform/DeLICM.cpp b/polly/lib/Transform/DeLICM.cpp index e6e76ec9930..68dfac43b15 100644 --- a/polly/lib/Transform/DeLICM.cpp +++ b/polly/lib/Transform/DeLICM.cpp @@ -666,6 +666,19 @@ private: /// For each PHI instance we can directly determine which was the incoming /// block, and hence derive which value the PHI has. /// + /// The returned relation generally is injective, meaning that every PHI write + /// has at most one (or zero, if the incoming block's branch does not jump to + /// the PHI's block) PHI Read that reads it. However, due to the SCoP's + /// parameter context it is possible a statement instance that would overwrite + /// the PHI scalar is not in the statement's domain and thus a PHI write + /// appear to be used twice. This is a static property, at runtime the + /// runtime condition should avoid that a configuration is executed. Although + /// incorrect, it should not have any effect in DeLICM. If it passes the + /// conflict check, there are multiple locations, one for each PHI Read it + /// matches, it had to write to. MemoryAccess::getAddressFunction() will + /// select only one of them. That is, statically, not all necessary value are + /// written, but the runtime check guards it from ever being executed. + /// /// @param SAI The ScopArrayInfo representing the PHI's storage. /// /// @return { DomainPHIRead[] -> DomainPHIWrite[] } @@ -702,7 +715,6 @@ private: isl_union_map_from_map(LastPerPHIWrites.take()), isl_union_map_reverse(PHIWriteScatter.take()))); assert(isl_union_map_is_single_valued(Result.keep()) == isl_bool_true); - assert(isl_union_map_is_injective(Result.keep()) == isl_bool_true); return Result; } |

