| commit | de7232ff6d33d83e6d2471511e8f3b7b92abba31 | |
| author | Tobias Grosser <tobias@grosser.es> | |
| Sat, 18 Mar 2017 20:10:07 +0000 (18 20:10 +0000) | ||
| committer | Tobias Grosser <tobias@grosser.es> | |
| Sat, 18 Mar 2017 20:10:07 +0000 (18 20:10 +0000) | ||
| tree | 1200223bac596a7b113f52f9b889d95ac6960159 | treesnapshot (tar.gz zip) |
| parent | a545ddd75591b05fb2aaa1daaefd507e18236ba2 | commitdiff |
[OpenMP] Do not emit lifetime markers for context
In commit r219005 lifetime markers have been introduced to mark the lifetime of
the OpenMP context data structure. However, their use seems incorrect and
recently caused a miscompile in ASC_Sequoia/CrystalMk after r298053 which was
not at all related to r298053. r298053 only caused a change in the loop order,
as this change resulted in a different isl internal representation which caused
the scheduler to derive a different schedule. This change then caused the IR to
change, which apparently created a pattern in which LLVM exploites the lifetime
markers. It seems we are using the OpenMP context outside of the lifetime
markers. Even though CrystalMk could probably be fixed by expanding the scope of
the lifetime markers, it is not clear what happens in case the OpenMP function
call is in a loop which will cause a sequence of starting and ending lifetimes.
As it is unlikely that the lifetime markers give any performance benefit, we
just drop them to remove complexity.
git-svn-id: https://llvm.org/svn/llvm-project/polly/trunk@298192 91177308-0d34-0410-b5e6-96231b3b80d8
In commit r219005 lifetime markers have been introduced to mark the lifetime of
the OpenMP context data structure. However, their use seems incorrect and
recently caused a miscompile in ASC_Sequoia/CrystalMk after r298053 which was
not at all related to r298053. r298053 only caused a change in the loop order,
as this change resulted in a different isl internal representation which caused
the scheduler to derive a different schedule. This change then caused the IR to
change, which apparently created a pattern in which LLVM exploites the lifetime
markers. It seems we are using the OpenMP context outside of the lifetime
markers. Even though CrystalMk could probably be fixed by expanding the scope of
the lifetime markers, it is not clear what happens in case the OpenMP function
call is in a loop which will cause a sequence of starting and ending lifetimes.
As it is unlikely that the lifetime markers give any performance benefit, we
just drop them to remove complexity.
git-svn-id: https://llvm.org/svn/llvm-project/polly/trunk@298192 91177308-0d34-0410-b5e6-96231b3b80d8