Re: [GSoC] Elimination of CLooG library installation dependency

[Tobias Grosser <tobias at grosser dot es>]

On 09/08/2014 12:05, Roman Gareev wrote:
> > With just C++ code, Sven can help little. He has no knowledge about graphite
> > internals.
>
> I want to ask him about correctness of ISL ASTs generated from
> mentioned isl_codegens.

I am not sure if he can see it just like this.

> > Do you now have a setup where you can just compile one of the attached files
> > with graphite and everything else without and the code crashes?
>
> No, I don't. As I mentioned earlier, all the files from this test case
> individually produce object files which linked into the one
> executable, which cause âSegmentation fault (core dumped)â (It'll
> cause âSegmentation fault (core dumped)â, if we try to run it). I
> think that it's very difficult to detach the code, which would produce
> the executable and save the semantics of this big OOP project.
> Furthermore, there is a possibility that the detached code can produce
> no new useful information.
>
> I've found that if we try to compile any of the btCollisionWorld.cpp,
> btCollisionDispatcher.cpp
> and btDiscreteDynamicsWorld.llvm.cpp by modified Graphite, the
> produced object file will lead to creation of the wrong executable
> (after linking with other object files generated by origin Graphite).

I am confused. It seems you attached some kind of reduced version of 
btCollisionWorld.cpp? How did you obtain it? Did you compile and test
with these versions?

> That's why I think that we could consider only, for example,
> btCollisionDispatcher.cpp. It contains only one scope, which is
> incorrectly processed by Graphite with the ISL code generator as the
> main generator.
>
> > Why did you provide two files. I assume one should be sufficient to
> > reproduce the crash, no?
>
> I've detached the code, which is used by Graphite to produce similar AST's.

OK. But did you check if they actually segfault or fail?

> > I think for the one file you choose, it would be interesting to look
> > at the code generation input as well as the kernels generated by CLooG and
> > isl. Maybe we can understand what is going on.

Yes, exactly those that you provided. At a first look, I don't see 
anything obvious wrong, except that the huge modulo values, which arise 
from some integer wrapping support Sebastian added once for unsigned 
integers.

I see two approaches you can take:

1) The easy one

Disallow unsigned integers in the scop detection. I have doubts we can 
do anything good with those huge modulo constraints placed all over the 
generated code

2) Try to understand the test case

I would try a couple of easy unsigned int loops to see if we can handle 
them properly. Something like:

for (unsigned long i = 0; i < M; i++)
  A[i] += i;

At best, we could even write your test case as such a loop and reproduce
the bug outside of this huge C++ code. Maybe looking at the GIMPLE 
allows you to write C code that has similar behavior and where we could 
check the output?

Tobias