This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [GSoC] Elimination of CLooG library installation dependency

On 09/08/2014 12:05, Roman Gareev wrote:
With just C++ code, Sven can help little. He has no knowledge about graphite

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,
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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]