First note:
IndependentBlocks::verifyScop(Region *R) is called 7 times (fyi, almost as
many times as there are baic blocks in the function) before the crash...
we should probably try to save some compile time here.

Second note:
I don't think we should pin everything on RTCs, this one included.

Third note, or what happends here:
Given two SCoPs S0 and S1 (or in the beginning two regions R0 and R1):
Assume R1 uses a value defined in R0 and we run now independent blocks on R0,
before the IR looked like this:

R0: X = ...
...
R1: ... X ...

after independent blocks:

R0: X = ...
store X X.alloca
...
R1: X' = load X.alloca
... X' ...

Thus it looks like everything is fine. However if X was e.g., involved in
the loop bound of any loop in R1 we will simply generate new code using X
with the scev-codegen interface.

Fourth note, or what to do about it:
Several things come to my mind but I'm not sure if they are actually all feasible:

1. Do not verify SCoP. This way we do not crash and at least in this example the code looks good.
2. Teach the independent block pass situations where escaping uses are OK.
   Here for example we verify the SCoP after it was build and we complain
   about an outside use that is dominated by the definition,.. no need to as
   we already changed the code and will not do it again.
3. Teach the scev codegen to respect independent blocks, thus to load values we promoted to the memory instead of using them directly. This way everything else can stay in place.

Fifth note:
I got a lot on my plate at the momemnt, so if someone want's to fix this I
would be thrilled ;). Once we decided what to do it is probably not even
that big of a deal.

First note:
IndependentBlocks::verifyScop(Region *R) is called 7 times (fyi, almost
as
many times as there are baic blocks in the function) before the crash...
we should probably try to save some compile time here.

I would like to eliminate it entirely. That's the reason the the scev based code generation. We also still need support to model scalars without translating them to arrays and then it can possibly fully eliminated.

Second note:
I don't think we should pin everything on RTCs, this one included.

This test case is really not related to run-time alias checks. I just verified it with running this command:

polly-opt alias-checks-two-scops-in-a-row.ll -polly-codegen-isl -polly-codegen-scev -polly-ignore-aliasing

I marked it as such as I did not had time to had time to look at the test case (even though it would have been easy to understand.

Third note, or what happends here:
Given two SCoPs S0 and S1 (or in the beginning two regions R0 and R1):
Assume R1 uses a value defined in R0 and we run now independent blocks on
R0,
before the IR looked like this:

R0: X = ...
...
R1: ... X ...

after independent blocks:

R0: X = ...
store X X.alloca
...
R1: X' = load X.alloca
... X' ...

Thus it looks like everything is fine. However if X was e.g., involved in
the loop bound of any loop in R1 we will simply generate new code using X
with the scev-codegen interface.

Thanks.

Fourth note, or what to do about it:
Several things come to my mind but I'm not sure if they are actually all
feasible:

1. Do not verify SCoP. This way we do not crash and at least in this
   example the code looks good.
2. Teach the independent block pass situations where escaping uses are OK.
   Here for example we verify the SCoP after it was build and we complain
   about an outside use that is dominated by the definition,.. no need to
   as
   we already changed the code and will not do it again.
3. Teach the scev codegen to respect independent blocks, thus to load
   values we promoted to the memory instead of using them directly. This way
   everything else can stay in place.

No idea yet. I need to think about this.

Fifth note:
I got a lot on my plate at the momemnt, so if someone want's to fix this I
would be thrilled ;). Once we decided what to do it is probably not even
that big of a deal.

Me as well (I want the openmp codegen out). As it is not RTC related, I may have a look myself. ;)

Tobias

*** Bug #12681 has been marked as a duplicate of this bug. ***

This very test case has been fixed in r222103.

The way how polly handles sequences of scops is still not perfect, but we should open a new bug report (with a corresponding test case) to track this.

Move to Polly Product.