[llvm-dev] Build polly-amd64-linux Failure

[Michael Kruse via llvm-dev]

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


2017-05-09 17:52 GMT+02:00 Tobias Grosser <tobias at grosser.es>:
> On Tue, May 9, 2017, at 05:08 PM, Michael Kruse via llvm-dev wrote:
>> 2017-05-06 16:46 GMT+02:00 Tobias Grosser <tobias at grosser.es>:
>> > On Sat, May 6, 2017, at 04:28 PM, llvm.buildmaster at lab.llvm.org wrote:
>> >> 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?
>>
>> No idea either. It worked reliably on the machines I tested with. I am
>> not even sure how to debug this difference.
>
> 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



-- 
Tardyzentrismus verboten!