Dear gcc contributors,
Recently I came across the list of "ideas for speeding up GCC"
(http://gcc.gnu.org/wiki/Speedup_areas). Among others, there was
suggested to replace identifier hash table with other data structure.
Please find attached a patch, that switches the resolution strategy of
a has
2013/10/20 Ondřej Bílka :
> On Sun, Oct 20, 2013 at 06:55:40PM +0600, Roman Gareev wrote:
>> Dear gcc contributors,
>>
>> Recently I came across the list of "ideas for speeding up GCC"
>> (http://gcc.gnu.org/wiki/Speedup_areas). Among others, there was
>>
2013/10/31 Florian Weimer :
> On 10/20/2013 02:55 PM, Roman Gareev wrote:
>>
>> During testing of the linux kernel (3.8.8) compilation time, the
>> acquired results were the following: increasing by 0.17% for the
>> version 4.8.0, increasing by 1.12% for the version 4.
at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/main.cpp:63
The executable is produced by compilation of 317 files. That's why I
think that it is be better to temporary postpone the consideration.
What do you think about this?
--
Cheers, Roman Ga
(scat_1);
}
}
}
is equivalent to
if (8*T_45 >= -T_44+9) {
for (scat_1=0;scat_1<=T_45-1;scat_1++) {
if ((8*scat_1+T_44)%18446744073709551616 <= -1) {
(scat_1);
}
}
}
If I'm not mistaken it's not equivalent to
for (int c1 = 0; c1 < P_45; c1 += 1)
if ((P_44 + 8 * c1) % 18446744073709551
gle
> function with graphite and that compiling this function causes the
> miscompile. This allows us to look at less code.
I've tried to reduce btCollisionWorld.cpp and
btCollisionDispatcher.cpp (They can be found attached). Should we ask
Sven?
--
C
_1<=T_2-1;scat_1++) {
if ((8*scat_1+T_11+18446744073709551615)%18446744073709551616 <=
18446744073709551614) {
(scat_1);
}
}
}
--
Cheers, Roman Gareev.
.cpp:232
#14 0x00401b12 in main (argc=, argv=)
at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/main.cpp:63
Could you please advise me an algorithm for pointer handling?
--
Cheers, Roman Gareev.
loop_0 (header = 0, latch = 1, niter = )
{
bb_2 (p
e error and
can be a temporary solution) Is the graphite_can_represent_scev an
appropriate place for the disabling of type handling?
--
Cheers, Roman Gareev.
Index: gcc/graphite-scop-detection.c
===
-
original bug report.
I’ve implemented this in the attached patch. Is it fine for trunk?
--
Cheers, Roman Gareev.
2014-08-12 Roman Gareev
[gcc/testsuite]
* gcc.dg/graphite/pr35356-2.c: Update according to the ISL code
generator.
Index: g
h.
Are they fine for trunk? Could we give a headsup on the GCC mailing
list and ask other people to try the new isl support in case this
patch is committed?
--
Cheers, Roman Gareev.
2014-07-12 Roman Gareev
gcc/
* graphite-scop-detection.c:
ndling of pointer types, because it’s currently not supported by
Graphite with the ISL AST generator. SSA_NAME nodes are the only
nodes, which are disabled in case they are pointers to object types,
but this can be changed.” ?
--
Cheers, Roman Gareev.
Thank you for the comment!
2014-08-13 15:55 GMT+06:00 Richard Biener :
> On Wed, Aug 13, 2014 at 10:07 AM, Roman Gareev wrote:
>> If I’m not mistaken all tree nodes, which have pointer type, can be
>> divided into two groups: the type is a is a pointer to data member
>> (
error. I want to commit it in coming days. What do you think
about it?
Maybe we should make the ISL AST generator to be the main code
generator of Graphite (the patch1 implements this). What do you think
about it?
--
Cheers, Roman Gareev.
2014-08-15 R
Richard, could you please review these patches? We would be very glad
for your comments.
P.S: I’ve attached an improved ChangeLog_entry.
2014-08-15 17:44 GMT+06:00 Richard Biener :
> On Fri, Aug 15, 2014 at 1:13 PM, Roman Gareev wrote:
>>> I've attached the patch, which shoul
r comments.
--
Cheers, Roman Gareev.
> This patch is ok. I assume you have tested compiling with/without cloog
> and isl.
Yes, I’ve tested compiling with/without cloog and isl. Thank you very
much for review!
--
Cheers, Roman Gareev.
porary/builds/fsf-trunk/502/workdir/aarch64-none-linux-gnu/obj/build-gcc/gcc'
> make: *** [all-gcc] Error 2
>
> Thanks,
> bin
--
Cheers, Roman Gareev.
l.10.dylib`domain_follows_at_depth +
> 112
> frame #14: 0x000141c7cdba libisl.10.dylib`isl_tarjan_components + 154
>
> getting to the ICE take ~19s compared to less than a second before r214069.
This is a bug in ISL. They’ll fix it in a new version of ISL.
https://groups.google.com/forum/#!topic/isl-development/SeNZf5IA-Lk
--
Cheers, Roman Gareev.
generation of ISL
AST, new switch, new testcase that checks that the dump is generated.
Is it fine for trunk?
P.S. My copyright assignment has been already processed.
--
Cheers, Roman Gareev
ChangeLog_entry1
Description: Binary data
ChangeLog_entry2
Thank you for the review!
--
Cheers, Roman Gareev
ChangeLog_entry1
Description: Binary data
ChangeLog_entry2
Description: Binary data
patch1
Description: Binary data
patch2
Description: Binary data
ile, root_node, scop->ctx);
+}
+ isl_ast_node_free (root_node);
+ timevar_pop (TV_GRAPHITE_CODE_GEN);
+ return !graphite_regenerate_error;
+}
diff --git a/gcc/graphite-isl-ast-to-gimple.h b/gcc/graphite-isl-ast-to-gimple.h
new file mode 100644
index 000..0d98780
--- /dev/null
+++ b/gcc/graphite-
This patch adds __isl_give to declarations of the following funcions:
generate_isl_context, generate_isl_schedule, scop_to_isl_ast
Is it fine for trunk?
--
Cheers, Roman Gareev
ChangeLog_entry
Description: Binary data
patch
Description: Binary data
Sorry, I was going to fix this. Thank you very much!
--
Cheers, Roman Gareev
Okay for gcc trunk?
> Jack
--
Cheers, Roman Gareev.
Hi Tobias,
I've attached a patch which removes using of CLooG library from
Graphite. Is it fine for trunk?
--
Cheers, Roman Gareev.
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (rev
ext patch?
--
Cheers, Roman Gareev.
difficult. I just wanted to reduce the
size of a patch which can be found below.
--
Cheers, Roman Gareev.
2014-11-9 Roman Gareev
[gcc/]
* Makefile.in: Remove the compilation of graphite-clast-to-gimple.o.
* common.opt: Remove using of fgraph
These are statistically significant differences: increasing by 0.23%
for the version 4.8.0, increasing by 0.21% for the version 4.8.1,
decreasing by 0.686% for trunk.
These are new row numbers:
2013-11-05 Roman Gareev :
> 2013/10/31 Florian Weimer :
>> On 10/20/2013 02:55 PM, Roman Gar
> Surprising. Is the symbol defined in libisl.so? You could use objdump to
> check?
If I am not mistaken, objdump shows that libisl.so contains it.
objdump -d libisl.so.10.2.2 | grep isl_ast_expr_get_val
00060380 :
60383: 74 4b je 603d0
60389: 75 0d
> The ChangeLog should be per-function. Otherwise LGTM.
I've fixed this.
--
Cheers, Roman Gareev
2014-07-04 Roman Gareev
gcc/
* graphite-isl-ast-to-gimple.c (generate_isl_context):
Add __isl_give to the dec
t;
> Is this needed? ip.region seems unused.
Yes, this is redundant.
I tried to incorporate all your comments in the attached patch.
--
Cheers, Roman Gareev.
Index: gcc/graphite-isl-ast-to-gimple.c
===
--- gcc/graphit
erring of sese region, which is used for translation of
an isl_ast_node_user to Gimple code. Should we transfer it separately
or restore ivs_params later? What do you think?
--
Cheers, Roman Gareev.
I've attached an improved version of the patch and the ChangeLog
entry. Are they fine for trunk?
--
Cheers, Roman Gareev.
2014-07-11 Roman Gareev
gcc/
* graphite-isl-ast-to-gimple.c (gmp_cst_to_tree):
New fun
ext_e;
}
Do you know anything about this?
--
Cheers, Roman Gareev.
2014-07-12 Roman Gareev
gcc/
* graphite-isl-ast-to-gimple.c:
Add inclusion of gimple-ssa.h, tree-into-ssa.h.
(ivs_params_clear):
Pass ivs_params
Hi Dominique,
thank you for the message! I've attached a patch, that may fix the issue.
Please report back if it fixes the problem.
--
Cheers, Roman Gareev.
Index: gcc/graphite-isl-ast-to-gim
,
/gcc/testsuite/gcc.dg/graphite/interchange-mvt.c,
/gcc/testsuite/gcc.dg/graphite/run-id-5.c?
(The result of the transformed function is compared to the assumed
value and the abort function is called in case of inequality.) What do
you think about this?
--
Cheers, R
ding to isl's ChangeLog, isl_val abstraction was added in version
0.12. Therefore, I think it would be right to demand on 0.12.
Tobias, what do you think about this? Is this fine for the backend,
which uses CLooG to generate Gimple code?
--
Cheers, Roman Gareev
at do you think
about this?
--
Cheers, Roman Gareev.
> Could you prepare such a patch?
Yes, I've started working on it.
I have a question about isl. Can we require that isl is always
compiled with GMP support?
--
Cheers, Roman Gareev
r (int c1 = 0; c1 <= -i + 49; c1 += 1)
S_4(c1);
}
2014-07-12 Roman Gareev
gcc/
* graphite-isl-ast-to-gimple.c:
Add inclusion of gimple-ssa.h, tree-into-ssa.h.
(ivs_params_clear):
(build_iv_mapping): New function.
(translate_isl_ast_node_use
I've attached the patch, which adds the requirement for isl 0.12.
Tobias, is it important to accept only 0.12.1, 0.12.2 and forbid 0.12?
--
Cheers, Roman Gareev
2014-07-12 Roman Gareev
* configure.ac: Don't accept isl 0.11.
*
the vector. We can later improve this.
Sorry, I, probably, mixed something up. This function was used in the
attached patch without rewriting of other functions.
--
Cheers, Roman Gareev.
2014-07-12 Roman Gareev
gcc/
* graphite-isl-ast-to-gim
and avoid using
unacceptable mode size. Tobias, what do you think about this?
--
Cheers, Roman Gareev
2014-07-08 Roman Gareev
gcc/
* graphite-isl-ast-to-gimple.c:
Add using of build_nonstandard_integer_type instead of
int128_integer_t
ame_uses, chrec_apply_map. We'll
also have to rewrite declarations of iv_map in
graphite-clast-to-gimple.c in this case.
Please correct me, if I am wrong.
--
Cheers, Roman Gareev.
s it fine for trunk?
--
Cheers, Roman Gareev.
2014-07-20 Roman Gareev
* configure.ac: Accept only CLooG 0.18.1.
* configure: Regenerate.
Index: configure
===
--- configure
This patch fixes a formatting issue related to the number of
characters in the line. Is it fine for trunk?
--
Cheers, Roman Gareev.
2014-07-20 Roman Gareev
gcc/
* graphite-isl-ast-to-gimple.c:
Fixes a formatting issue related to the
Maybe we should temporary postpone this and add a FIXME that says:
“We should remove iv_map.create (loop->num + 1), if it is possible.”
What do you think about this?
--
Cheers, Roman Gareev.
I've asked the community about this.
The patch below contains the FIXME.
--
Cheers, Roman Gareev.
2014-07-12 Roman Gareev
gcc/
* graphite-isl-ast-to-gimple.c:
Add inclusion of gimple-ssa.h, tree-into-ssa.h.
(ivs_params_
I've attached the patch, which contains generation of Gimple code from
isl_ast_node_block. Is it fine for trunk?
--
Cheers, Roman Gareev.
2014-07-22 Roman Gareev
gcc/
* graphite-isl-ast-to-gimple.c:
(translate_isl_ast_node_block)
I've attached the patch, which adds the extension of all schedules to
the maximal number of schedule dimensions. It is necessary for the
proper work of the isl AST generator. Is it fine for trunk?
--
Cheers, Roman Gareev.
2014-07-22 Roman Gareev
it fine for trunk?
--
Cheers, Roman Gareev.
2014-07-23 Roman Gareev
[gcc/]
* graphite-isl-ast-to-gimple.c:
(binary_op_to_tree): Add new cases.
(gcc_expression_from_isl_expr_op): Move isl_ast_op_pdiv_q,
isl_ast_op_pdiv_r to d
corresponding test case. Is it fine for trunk?
--
Cheers, Roman Gareev.
2014-07-23 Roman Gareev
[gcc/]
* graphite-isl-ast-to-gimple.c:
(graphite_create_new_loop): Add calling of isl_id_free.
[gcc/testsuite]
* gcc.dg/graphite/
New testcase.
>
> Please fix the ChangeLog entries; no need to add another one for that
> change or ask for approval: such a fix is obvious.
Thank you for the comment!
--
Cheers, Roman Gareev.
pdiv_r. What do you think about this?
> Can you initialize res outside of the loop?
Yes, I've implemented this in the improved version.
--
Cheers, Roman Gareev.
= 0;
for (i = 0; i < 50; i++)
{
if (i >= 25)
res += i;
}
return res;
}
extern void abort ();
int
main (void)
{
int res = foo ();
if (res != 1225)
abort ();
return 0;
}
--
Cheers, Roman Gareev.
Inde
> Is there a reason you have those global values? To my understanding they
> could possibly just be function parameters?
Yes, it would be fine for this test case. I've implemented this in the
improved version.
--
Cheers, Roman Gareev.
2014-07-23 R
file, stmt, 0, TDF_SLIM);
}
Could you please advise me possible functions from
graphite-sese-to-poly.c, which can delete this?
P.S.: Only S_3 has this problem in the example.
--
Cheers, Roman Gareev.
;domain and the
pbb->transformed point to the old pbb with index 3.
I've attached the patch, which may fix this.
--
Cheers, Roman Gareev.
Index: gcc/graphite-sese-to-poly.c
===
--- gcc/grap
case. Should we create
another one?
--
Cheers, Roman Gareev.
2014-07-26 Roman Gareev
[gcc/]
* graphite-sese-to-poly.c:
(new_pbb_from_pbb): Set a new id of pbb1->domain (instead of using the
id of the pbb), which contains pointer to the
re S_9 has pbb->domain and pbb->transformed of S_3. A pointer to a
Gimple basic block is not NULL now, but it leads to the wrong answer.
I've tried different examples, which generate ISL AST, but they have
same problems. Could you please advise me another one?
--
t c2 = 0; c2 <= 1; c2 += 1)
S_3(c1);
if (c1 <= 4)
S_4(c1);
S_5(c1);
}
S_7();
}
Maybe we could use it. What do you think about this?
--
Cheers, Roman Gareev.
wrong answer without patch1. The code is transformed
correctly with this patch.
--
Cheers, Roman Gareev.
ccording to the comment of the rewrite_reductions_out_of_ssa (this
function duplicates pbbs), the rewrite_reductions_out_of_ssa rewrite
out of SSA all the reduction phi nodes of SCOP. What are reduction phi
nodes? How are they related to 'reduction'?
--
Cheers, Roman Gareev.
've also checked that pbbs correspond to pbbs of pbb->domain and
pbb->transformed.
--
Cheers, Roman Gareev.
2014-07-23 Roman Gareev
[gcc/]
* graphite-isl-ast-to-gimple.c:
(graphite_create_new_guard): New function.
(translat
Should we remove /* { dg-final { scan-tree-dump-times
"MIN_EXPR\[^\\n\\r]*;" 4 "graphite" } } */ from this test case?
P.S.: The other graphite tests (except vect-pr43423.c) are passed by
graphite in case we run it with the ISL AST generator.
--
Chee
e isl mailing list.
> What is the problem with this last test case?
It is related to checking for the loop parallelism, which is not yet
implemented in the current version of graphite-isl-ast-to-gimple.c.
--
Cheers, Roman Garee
the isl-0.13 is
also not optimal (I sent you the code generated by isl-0.12.2 before).
The report has been sent to the isl mailing list and CC you.
--
Cheers, Roman Gareev.
Could you please advise me how is it better to answer the following
questions of Sven:
> In what way is it "not optimal"?
> That is, what are your optimality criteria?
(I could answer them, but I don't want to miss anything)
--
Cheers, Roman Gareev.
S_6(c1);
} else
S_7(c1);
S_8(c1);
}
I think it can't be parallelized. Maybe this example is no more
suitable. What do you think about this?
--
Cheers, Roman Gareev.
Index: gcc/graphite-isl-ast-to-gimple.c
If I'm not mistaken, the carries_deps functions can't be called in
graphite-isl-ast-to-gimple.c. Should we add its declaration to
graphite-poly.h to allow this?
--
Cheers, Roman Gareev.
vect-pr43423.c.114t.vect(cloog)
Description: Binary data
vect-pr43423.c.114t.vect(isl)
Description: Binary data
Sorry for misprints
> Graphite successfully passes all the tests from
> libgomp/testsuite/libgomp.graphite except graphite-isl-ast-to-gimple.c
> and graphite-poly.h
except force-parallel-5.c and force-parallel-8.c
--
Cheers, Roman Gareev.
ormulate it?)
--
Cheers, Roman Gareev.
Cheers, Roman Gareev.
2014-08-4 Roman Gareev
[gcc/]
* graphite-isl-ast-to-gimple.c: Add a new struct ast_build_info.
(translate_isl_ast_for_loop): Add checking of the
flag_loop_parallelize_all.
(ast_build_before_for): New function.
(s
-to-gimple.c.
--
Cheers, Roman Gareev.
I've attached the patch, which sets the separate option for all
dimensions. Is it fine for trunk?
--
Cheers, Roman Gareev.
2014-08-05 Roman Gareev
[gcc/]
* graphite-isl-ast-to-gimple.c:
(set_options): New fun
pr35356-2.c to be similar to isl-codegen-loop-dumping.c
by replacing “MIN_EXPR\[^\\n\\r]*;" and "MAX_EXPR\[^\\n\\r]*;" with
the regexp, which contains the the above-mentioned isl ast?
--
Cheers, Roman Gareev.
r manually changed? (I haven't
found out how to regenerate it.)
I've used printf to print “The CLooG code generator cannot be used
+(CLooG is not available). The ISL code generator was chosen.\n”.
Should another function be used for this purpose?
--
.
Tested x86_64-unknown-linux-gnu, applying to 4.8.3 and trunk.
2014-03-07 Roman Gareev
gcc/
* graphite-dependences.c
(subtract_commutative_associative_deps):
Add NULL checking of the following variables:
must_raw_no_source, may_raw_no_source
Sorry, an error occurred somewhere. Below is an attachment with the
patch and ChangeLog entry.
> This patch fixes the following bug:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59586.
> The segfault is caused by NULL arguments passed to compute_deps by
> loop_level_carries_dependences.
> This ca
xp, 1, x, 1 )
>> + endif
>> + end
>>
>
I tried to add a testcase, which uses example introduced in bug
report. Sorry for making an error in encoding options.
--
Roman Gareev
>
> I agree this is really horribly ugly. Can't you just use
> ! { dg-additional-options "-Ofast -floop-parallelize-all" }
> in the testcase?
> I thought the ugliness of encoding options in test filenames was */vect/
> only, apparently it affects also */graphite/ :(.
>
> Jakub
--
Roman Gareev
This patch fixes PR59586.
The segfault is caused by NULL arguments passed to compute_deps by
loop_level_carries_dependences.
This causes an assignment of NULL values to the no_source parameters
of compute_deps.
They are passed to subtract_commutative_associative_deps and dereferenced.
However, thi
Hi Mircea,
sorry for making you wait.
--
Roman Gareev
patch
Description: Binary data
ChangeLog_entry
Description: Binary data
84 matches
Mail list logo
