Check whether IslAstInfo and DependenceInfo were computed for the same Scop.
commit6c392b420026404dc8f03e0d6cde6424a17ba275
authorMichael Kruse <llvm@meinersbur.de>
Thu, 21 Sep 2017 00:01:13 +0000 (21 00:01 +0000)
committerMichael Kruse <llvm@meinersbur.de>
Thu, 21 Sep 2017 00:01:13 +0000 (21 00:01 +0000)
treee433c531569a0f401f33dfeb9bc08321e746bc44
parentf0d1b78a04ac74dd201b9f5c847e52df55409720
Check whether IslAstInfo and DependenceInfo were computed for the same Scop.

Since -polly-codegen reports itself to preserve DependenceInfo and IslAstInfo,
we might get those analysis that were computed by a different ScopInfo for a
different Scop structure. This would be unfortunate because DependenceInfo and
IslAstInfo hold references to resources allocated by
ScopInfo/ScopBuilder/Scop (e.g. isl_id). If -polly-codegen and
DependenceInfo/IslAstInfo do not agree on which Scop to use, unpredictable
things can happen.

When the ScopInfo/Scop object is freed, there is a high probability that the
new ScopInfo/Scop object will be created at the same heap position with the
same address. Comparing whether the Scop or ScopInfo address is the expected
therefore is unreliable.

Instead, we compare the address of the isl_ctx object. Both, DependenceInfo
and IslAstInfo must hold a reference to the isl_ctx object to ensure it is
not freed before the destruction of those analyses which might happen after
the destruction of the Scop/ScopInfo they refer to.  Hence, the isl_ctx
will not be freed and its address not reused as long there is a
DependenceInfo or IslAstInfo around.

This fixes llvm.org/PR34441

git-svn-id: https://llvm.org/svn/llvm-project/polly/trunk@313842 91177308-0d34-0410-b5e6-96231b3b80d8
include/polly/CodeGen/IslAst.h
include/polly/DependenceInfo.h
lib/CodeGen/CodeGeneration.cpp
lib/CodeGen/IslAst.cpp
lib/Transform/ScheduleOptimizer.cpp
test/Isl/CodeGen/multiple-codegens.ll [new file with mode: 0644]
test/ScopDetect/base_pointer_load_setNewAccessRelation.ll