On 27/07/2014 12:48, Roman Gareev wrote:
Thank you! I've attached patches with a test case (it is located in
patch1.txt), which generates the following ISL AST:
for (int c1 = 0; c1 <= 49; c1 += 1) {
if (c1 <= 24)
S_4(c1);
S_5(c1);
}
I think that it doesn't contain reduction and doesn
Thank you! I've attached patches with a test case (it is located in
patch1.txt), which generates the following ISL AST:
for (int c1 = 0; c1 <= 49; c1 += 1) {
if (c1 <= 24)
S_4(c1);
S_5(c1);
}
I think that it doesn't contain reduction and doesn't yield several
bbs. I've also checked that p
On 27/07/2014 08:12, Roman Gareev wrote:
Can you explain why you believe it is hard/impossible to generate a test
case without reduction?
I don't believe this. I only know that all the test cases considered
by me have the same problem.
Could you please explain what is 'reduction'? I've found o
> Can you explain why you believe it is hard/impossible to generate a test
> case without reduction?
I don't believe this. I only know that all the test cases considered
by me have the same problem.
Could you please explain what is 'reduction'? I've found out that,
according to the comment of the
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
> 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
On 26/07/2014 15:48, Roman Gareev wrote:
What do you mean by wrong answer? Is there still a bug in the code
generation or the AST is just more complex as expected.
I mean that the value of res is wrong. I think it is because of the
wrong id of pbb->domain and pbb->transformed inherited from S_3
> What do you mean by wrong answer? Is there still a bug in the code
> generation or the AST is just more complex as expected.
I mean that the value of res is wrong. I think it is because of the
wrong id of pbb->domain and pbb->transformed inherited from S_3 by S_9
(It was correct for S_3, but it
On 26/07/2014 14:59, Roman Gareev wrote:
I've tried to compile your example and had the similar problem. It
generates the following ISL AST
{
for (int c1 = 0; c1 <= 49; c1 += 1) {
S_6(c1);
if (c1 <= 48) {
S_3(c1);
S_9(c1);
if (c1 >= 24)
S_4(c1);
I've tried to compile your example and had the similar problem. It
generates the following ISL AST
{
for (int c1 = 0; c1 <= 49; c1 += 1) {
S_6(c1);
if (c1 <= 48) {
S_3(c1);
S_9(c1);
if (c1 >= 24)
S_4(c1);
S_5(c1);
}
}
S_7();
}
where S_9 has pbb-
On 26/07/2014 11:53, Roman Gareev wrote:
Any reason you don't use isl_id_for_pbb() to create this isl_id?
Yes, it is redundant. I've used isl_id_for_pbb() in the improved version.
Otherwise, the patch looks good to me. You can commit it if the graphite tests
still pass and you add an appropr
> Any reason you don't use isl_id_for_pbb() to create this isl_id?
Yes, it is redundant. I've used isl_id_for_pbb() in the improved version.
> Otherwise, the patch looks good to me. You can commit it if the graphite
> tests still pass and you add an appropriate ChangeLog entry.
I haven't found
On 24/07/2014 12:09, Roman Gareev wrote:
I've attached the patch, which contains generation of Gimple code from
isl_ast_node_if.
However, I've found out a problem. When I'm trying to generate Gimple
code from, for example, the following ISL AST:
{
for (int c1 = 0; c1 <= 49; c1 += 1) {
S
On 26/07/2014 10:59, Roman Gareev wrote:
If I'm not mistaken, the reason of this bug is incorrect creation of a
poly_bb_p for basic_block from the existing pbb in new_pbb_from_pbb
(It is located in graphite-sese-to-poly.c). I think, that we should
set a new id of pbb1->domain (instead of using th
If I'm not mistaken, the reason of this bug is incorrect creation of a
poly_bb_p for basic_block from the existing pbb in new_pbb_from_pbb
(It is located in graphite-sese-to-poly.c). I think, that we should
set a new id of pbb1->domain (instead of using the id of the pbb),
which contains pointer to
On 25/07/2014 13:20, Roman Gareev wrote:
I have no idea. Is the Gimple basic block of S_3 never set, or is it set and
deleted on the way?
I think, that it is deleted on the way. I've found out, that the
Gimple basic block will be set, if we add the following code to the
generate_isl_schedule:
> I have no idea. Is the Gimple basic block of S_3 never set, or is it set and
> deleted on the way?
I think, that it is deleted on the way. I've found out, that the
Gimple basic block will be set, if we add the following code to the
generate_isl_schedule:
bb_schedule = isl_map_set_tuple_id (bb_s
On 24/07/2014 12:09, Roman Gareev wrote:
I've attached the patch, which contains generation of Gimple code from
isl_ast_node_if.
Nice.
However, I've found out a problem. When I'm trying to generate Gimple
code from, for example, the following ISL AST:
{
for (int c1 = 0; c1 <= 49; c1 += 1)
I've attached the patch, which contains generation of Gimple code from
isl_ast_node_if.
However, I've found out a problem. When I'm trying to generate Gimple
code from, for example, the following ISL AST:
{
for (int c1 = 0; c1 <= 49; c1 += 1) {
S_6(c1);
if (c1 <= 48) {
S_3(c1);
19 matches
Mail list logo
