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
