On 26/07/2014 16:16, Roman Gareev wrote:
I would still add a test case which does not contain a reduction (+=)
and where graphite is not duplicating pbbs.
Help for what? I was looking to create a simple test case. Is there still an
open bug?
Sorry, I thought, we should add this test case to be able to test
graphite without patch related to graphite-sese-to-poly.c (patch1).
Right. I think we should have a simple test case that does not trigger
basic block duplication, which is basically triggered for reductions.
The test case:
static int __attribute__((noinline))
foo ()
{
int i, res = 0;
for (i = 0; i < 50; i++)
{
if (i < 5)
res += 1;
}
return res;
}
that you just proposed contains again a reduction and yields several bbs
that cause problems.
{
for (int c1 = 0; c1 <= 49; c1 += 1) {
for (int c2 = 0; c2 <= 1; c2 += 1)
S_3(c1);
if (c1 <= 4)
S_4(c1);
S_5(c1);
}
S_7();
}
I proposed a test case without a reduction (possibly a little bit more
complex):
> > for i:
> > A[i] = ...
> >
> > You could do the summation/verfication outside of the scop e.g. in
> > the main
> > function.
>
> It seems that it doesn't help (at least for now).
Can you explain why you believe it is hard/impossible to generate a test
case without reduction?
Sorry Roman. I am still confused. Are we looking for a test case or are we
still trying to understand an issue. Specifically, do we still incorrectly
transform the code even after your isl_id_for_pbb() patch?
I gives a wrong answer without patch1. The code is transformed
correctly with this patch.
OK. So we don't need to solve another bug. That is good.
Cheers,
Tobias