Build polly-amd64-linux Failure

The Buildbot has detected a failed build on builder polly-amd64-linux
while building polly.
Full details are available at:
http://lab.llvm.org:8011/builders/polly-amd64-linux/builds/6539

Buildbot URL: http://lab.llvm.org:8011/

Buildslave for this Build: grosser1

Build Reason: scheduler
Build Source Stamp: [branch trunk] 302339
Blamelist: meinersbur

Hi Michael,

the recent commit caused a failure:

/home/grosser/buildslave/polly-amd64-linux/llvm.src/tools/polly/test/DeLICM/reduction_overapproximate.ll:102:16:
error: expected string not found in input
; APPROX-NEXT: new: { Stmt_reduction_inc[i0, i1] -> MemRef_A[2] : i0 <=
3 and 0 <= i1 <= -2 + i0 };
               ^
<stdin>:62:2: note: scanning from here
new: { Stmt_reduction_inc[i0, i1] -> MemRef_A[2] : 2 <= i0 <= 3 and 0
<= i1 <= -2 + i0 };

I have no idea where it comes from. On my machine (and my earlier tests)
show no issues. Any ideas?

Best,
Tobias

No idea either. It worked reliably on the machines I tested with. I am
not even sure how to debug this difference.

Michael

The sets we obtain are semantically identical, but have a different
representation. So it does not seem to be a correctness issue. Still, it
would be good if we can resolve this at some point.

Maybe open a bug report for now that we don't forget.

My first shot would be to compile a Release - no asserts of Polly and
see if the same results are obtained. My guess is that some of your
ASSERT statements cause isl to simplify constraints on the way, which
may not happen in a release build. If this is indeed the case, I do not
have a good answer how to address this.

Best,
Tobias

Hi Tobias,

the assert was a good hint. This line causes it:

assert(!Result ||
           isl_set_is_equal(give(isl_map_domain(Result.copy())).keep(),
                            Domain.keep()) == isl_bool_true);

isl_set_is_equal calls isl_map_normalize which does not do a
copy-on-write, hence modifies the original argument. Not sure whether
this is a bug or feature in isl.

This fixes the problem:

   /// Get the domain of @p Stmt.
   isl::set getDomainFor(ScopStmt *Stmt) const {
- return give(Stmt->getDomain());
+ return give(isl_set_remove_redundancies( Stmt->getDomain()));
   }

The redundancy is inherited from the statement's domain

       Stmt_reduction_inc
            Domain :=
                { Stmt_reduction_inc[i0, i1] : 2 <= i0 <= 3 and 0 <=
i1 <= -2 + i0 };

I am currently waiting the current compilation failure to be fixed,
before I commit.

Michael