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
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
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
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
On 29/07/2014 12:14, Roman Gareev wrote:
I've tested Graphite with the ISL AST generator as the main code
generator and found out the following problem: in the current
implementation the gcc_expression_from_isl_ast_expr_id can return a
tree of a type, which doesn't correspond to the type chosen f
On 30/07/2014 09:56, Roman Gareev wrote:
Blindly converting type sizes is not a good idea and may be problematic when
>we switch to smaller types. As we can obviously only improve this when we
>have the appropriate support in isl, I think the attached patch is fine.
>However, please add a fixme t
On 30/07/2014 14:32, Roman Gareev wrote:
OK. I proposed a slightly longer description. With the updated description,
you can commit this patch.
I've fixed the fixme.
FIXME: We should replace blind conversation of id's type with
derivation of the optimal type when we get the corresponding isl
s
On 31/07/2014 08:19, Roman Gareev wrote:
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)
Don't worry. Just give it a s
On 02/08/2014 11:49, Roman Gareev wrote:
Hi Roman,
>
>you can get this information from the isl_ast_build that was used when
>generating a certain loop (you can access this isl_ast_build from the
>callbacks isl_ast_build_set_before_each_for and
>isl_ast_build_set_after_each_for). With isl_ast_bui
On 03/08/2014 16:05, Roman Gareev wrote:
This looks very similar to what we reported to the isl mailing list. It is
definitely not the best test case for the parallelism patch. In fact, I
doubt this requires the parallelism test at all.
I've found out, that Graphite generates the expected code
On 04/08/2014 08:09, Roman Gareev wrote:
Those waw dependences seem to be correct. Should even the previous analysis
only mark the j-loop as parallel?
The previous and the current analysis mark the j-loop as
nonparallelizable. (Possibly, I don't fully understand the question.
Could you please r
LGTM.
Cheers,
Tobias
On 04/08/2014 16:23, Roman Gareev wrote:
I would expect the to mark the i loop as non-parallel, but the j-loop
as parallel. What is the partial schedule, the set of dependences and
the dimension you check for both the i and the j loop?
Yes, you are right. The i loop is non-parallel and j-loop i
On 05/08/2014 06:02, Roman Gareev wrote:
I've attached the patch, which sets the separate option for all
dimensions. Is it fine for trunk?
LGTM.
Tobias
On 06/08/2014 17:21, Roman Gareev wrote:
I've tested the modified version of Graphite using the gcc test suite
and haven't found out new failed tests.
However, pr35356-2.c is still not suitable for testing. The ISL AST
generated from its source code doesn't contain MIN or MAX.
if (k <= -1)
On 06/08/2014 17:21, Roman Gareev wrote:
Hi Tobias,
I've attached the patch, which should eliminate CLooG library
installation dependency from GCC. The CLooG AST generator is still the
main code generator, but the isl ast generator will be chosen in case
of nonavailability of CLooG library.
Ni
I worked with Roman on this patch and believe it is technically correct.
Some tiny comments inline.
Tobias
On 03/08/2014 10:57 AM, Roman Gareev wrote:
This patch fixes the following bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59586.
I would write PR59586. This should make this patch sh
On 03/10/2014 03:51 PM, Roman Gareev wrote:
I am slightly surprised why this change is necessary. Roman, can you shade some
light on this change.
No worries, just follow the pattern Jakub proposed.
The patch submission was generally of very high quality.
Tobias
On 01/14/2013 03:29 PM, Richard Biener wrote:
This makes us accept the CLooG 0.18.0 and ISL 0.11.1 combo.
It's probably not the best stage to move the version checks to
gcc/ where we can rely on built in-tree ISL/CLooG, so this avoids
it with the caveat that in-tree CLooG 0.18.0 will fail the
v
On 08/26/2012 02:20 PM, Gerald Pfeifer wrote:
On Wed, 22 Aug 2012, Art Haas wrote:
I've been having to make this small change to the 'configure' script
when building on sparc-sun-solaris2.10 to accomodate the shell executing
the script. Without the change, I get an error message like so:
config
On 06/22/2012 01:38 PM, Richard Guenther wrote:
This cherry-picks two fixes from the move-to-isl-and-isl-scheduler
git graphite branch.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Hi Richard,
if this patches still pass tests, it would be great to see them committed.
Tobi
On 06/25/2012 09:59 AM, Richard Guenther wrote:
On Fri, 22 Jun 2012, Richard Guenther wrote:
This bumps the requirement to enable Graphite to using cloog 0.17.0
which is the last release from upstream. The patch removes the
support for the legacy cloog versions, too.
I am bootstrapping and t
On 06/27/2012 05:06 PM, Richard Guenther wrote:
This merges from the graphite branch the move of PPL to ISL,
and completes it where it was lacking - thanks to Micha.
It leaves unmerged the addition of a pluto-like ISL optimizer
as well as a bugfix for stride> 1 which did not come with
a testcas
On 06/26/2012 12:21 PM, Michael Matz wrote:
Hi,
so, to make progress on the graphite front we want to get rid of the ppl
dependency. We start from Tobis move-to-isl-and-isl-scheduler branch at
github, merged current trunk into that (see also Richis mails about
cloog/isl configury), and add ISL
On 07/02/2012 01:32 PM, Michael Matz wrote:
Hi Tobi,
On Fri, 29 Jun 2012, Tobias Grosser wrote:
+static isl_constraint *
+build_linearized_memory_access (isl_map *map, poly_dr_p pdr)
+{
+}
The function itself looks correct. However, I would personally have returned
an isl_map instead of an
On 07/02/2012 01:32 PM, Michael Matz wrote:
+++ b/gcc/graphite.c
@@ -253,6 +253,8 @@ graphite_finalize (bool need_cfg_cleanup_p)
print_loops (dump_file, 3);
}
+isl_ctx *the_isl_ctx;
Why are you creating a global ctx here?
For the printer, before I was aware of the fact that of cour
On 07/03/2012 12:12 PM, Richard Guenther wrote:
On Tue, 3 Jul 2012, Richard Guenther wrote:
On Tue, 3 Jul 2012, Richard Guenther wrote:
On Tue, 3 Jul 2012, Richard Guenther wrote:
On Tue, 3 Jul 2012, Richard Guenther wrote:
On Mon, 2 Jul 2012, Nenad Vukicevic wrote:
On 6/27/2012 8:06 AM
On 07/03/2012 01:15 PM, Richard Guenther wrote:
This merges the last bit from the graphite ISL branch - an
integrated optimizer based on ISL. To quote Tobias:
"The isl scheduling optimizer implements the scheduling algorithm first
developed in Pluto [1]. Pluto has shown significant speedups an
On 07/03/2012 01:56 PM, Richard Guenther wrote:
On Tue, 3 Jul 2012, Tobias Grosser wrote:
On 07/03/2012 01:15 PM, Richard Guenther wrote:
This merges the last bit from the graphite ISL branch - an
integrated optimizer based on ISL. To quote Tobias:
"The isl scheduling optimizer imple
On 07/03/2012 02:24 PM, Richard Guenther wrote:
On Tue, 3 Jul 2012, Tobias Grosser wrote:
On 07/03/2012 01:56 PM, Richard Guenther wrote:
On Tue, 3 Jul 2012, Tobias Grosser wrote:
On 07/03/2012 01:15 PM, Richard Guenther wrote:
This merges the last bit from the graphite ISL branch - an
On 07/04/2012 08:51 AM, Terry Guo wrote:
Hi Richard,
What's the plan for 4.7 branch? Will you back port this patch to 4.7 and
make it use ISL too? I am going to create a upstream GCC SVN branch from 4.7
for development on ARM embedded processors. If there will be some big
changes for 4.7 in near
7/msg01892.html
>From f07adb059a8793378073a2f4b2a6d1702c56771b Mon Sep 17 00:00:00 2001
From: Tobias Grosser
Date: Tue, 9 Aug 2011 18:26:28 +0100
Subject: [PATCH] Move to new Cloog interface.
* graphite-clast-to-gimple.c (new_clast_name_index): Store a copy
of the string, no jus
,
Sebastian
On Thu, Jul 21, 2011 at 18:00, Tobias Grosser wrote:
2011-07-21 Tobias Grosser
* configure: Regenerated.
* config/cloog.m4: Remove support for CLooG-ppl and CLooG-parma,
both cloog.org and legacy versions. The only supported version will
be CLooG with the isl
Thanks,
Sebastian
On Thu, Jul 21, 2011 at 18:00, Tobias Grosser wrote:
2011-07-21 Tobias Grosser
* configure: Regenerated.
* configure.ac: Require cloog isl 0.16.3
---
ChangeLog|5 +
configure|6 +++---
configure.ac |2 +-
3 files changed, 9
-patches/2011-08/msg00976.html
On Thu, Jul 21, 2011 at 18:00, Tobias Grosser wrote:
2011-07-21 Tobias Grosser
* configure: Regenerated.
* config/cloog.m4: Do not define CLOOG_ORG
and in gcc/
2011-07-21 Tobias Grosser
* Makefile.in (graphite-clast-to-gimple.o, graphite
).
Cheers
Tobi
>From f4f40f7a67710ac61c38991661e86b5a63820f2b Mon Sep 17 00:00:00 2001
From: Tobias Grosser
Date: Tue, 9 Aug 2011 18:26:28 +0100
Subject: [PATCH] Move to new Cloog interface.
* graphite-clast-to-gimple.c (new_clast_name_index): Store a copy
of the string, no just a refere
On 08/11/2011 07:03 PM, Sebastian Pop wrote:
On Thu, Aug 11, 2011 at 12:52, Tobias Grosser wrote:
I will commit this patch after the configure changes are in (and meanwhile
no further improvements were suggested for this patch).
Ok, thanks. Let's hope we will have a configure maint
On 08/11/2011 07:16 PM, Sebastian Pop wrote:
On Thu, Aug 11, 2011 at 13:03, Sebastian Pop wrote:
> On Thu, Aug 11, 2011 at 12:52, Tobias Grosser wrote:
>> I will commit this patch after the configure changes are in (and meanwhile
>> no further improvements were suggested
diff --git a/gcc/graphite.c b/gcc/graphite.c
index 8f6d8a1..b2cf7c6 100644
--- a/gcc/graphite.c
+++ b/gcc/graphite.c
@@ -260,10 +260,12 @@ graphite_transform_loops (void)
bool need_cfg_cleanup_p = false;
VEC (scop_p, heap) *scops = NULL;
htab_t bb_pbb_mapping;
+ isl_ctx *ctx;
if
On 08/15/2011 08:19 AM, Sebastian Pop wrote:
Hi,
This patch still needs some changes to ISL for the compile time
version check to work:
[#if ISL_VERSION_MAJOR != $1 \
|| ISL_VERSION_MINOR != $2 \
|| ISL_VERSION_REVISION< $3
I am providing this patch for reference, just in case IS
On 08/29/2011 04:01 PM, Joseph S. Myers wrote:
I looked at the ISL sources and saw that they generally had license
notices of the form:
* Use of this software is governed by the GNU LGPLv2.1 license
Hi Joseph,
at least according to a license compatibility chart[1] published by the
FSF, it i
On 09/29/2011 09:58 AM, Richard Guenther wrote:
On Thu, Sep 29, 2011 at 12:10 AM, William J. Schmidt
wrote:
Hi there,
Ping. I'm seeking approval for this fix on trunk and 4_6-branch.
Thanks!
Ok.
Yes, also looks good from me. Though, you may want to move the forward
declaration after the "
On 01/09/2012 04:31 PM, Richard Guenther wrote:
We have two Graphite related release blockers for 4.7. The
following patch fixes the first one.
Hi Richard,
thanks a lot for working on this.
The asserts in
static inline ppl_dimension_type
psct_dynamic_dim (poly_bb_p pbb, graphite_dim_t lev
On 01/09/2012 04:34 PM, Richard Guenther wrote:
This fixes the 2nd P1 ICE.
There is a disconnect on how we analyze data-references during SCOP
detection
(outermost_loop is the root of the loop tree) and during SESE-to-poly
where
outermost is determined by outermost_loop_in_sese_1 (). That infl
On 01/10/2012 10:14 AM, Richard Guenther wrote:
On Mon, 9 Jan 2012, Tobias Grosser wrote:
On 01/09/2012 04:34 PM, Richard Guenther wrote:
This fixes the 2nd P1 ICE.
There is a disconnect on how we analyze data-references during SCOP
detection
(outermost_loop is the root of the loop tree
On 02/15/2012 01:14 PM, Richard Guenther wrote:
This patch by Tobias fixes PR50561.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Thanks Richard.
Tobi
On 06/29/2011 12:35 PM, Sebastian Pop wrote:
2011-06-29 Sebastian Pop
* graphite-clast-to-gimple.c (precision_for_value): Removed.
(precision_for_interval): Removed.
(gcc_type_for_interval): Use mpz_sizeinbase.
-/* Return a type that could represent the integer value VAL
On 06/29/2011 12:35 PM, Sebastian Pop wrote:
Hi,
the following patch set fixes PR47654:
Correct typo.
Correct computation of max.
Fix PR47654: Loop blocking should strip-mine at least two loops.
Those three look OK.
Cheers
Tobi
On 06/29/2011 12:35 PM, Sebastian Pop wrote:
2011-06-29 Sebastian Pop
* graphite-clast-to-gimple.c (compute_bounds_for_level): Removed.
(compute_type_for_level): Removed.
(clast_get_body_of_loop): Removed.
(gcc_type_for_iv_of_clast_loop): Removed.
(graphi
On 06/29/2011 12:35 PM, Sebastian Pop wrote:
2011-06-29 Sebastian Pop
PR tree-optimization/47654
* graphite-clast-to-gimple.c (gcc_type_for_value): Removed.
(gcc_type_for_clast_term): Removed.
(gcc_type_for_clast_red): Removed.
(gcc_type_for_clast_bin): R
On 06/30/2011 09:50 AM, Sebastian Pop wrote:
On Wed, Jun 29, 2011 at 18:16, Tobias Grosser wrote:
why do we continue to call low 'low' and up 'up', if we actually just have
two values v1 and v2 where we do not know which one is larger? I think this
wrong and probably comes
On 06/30/2011 11:01 AM, Sebastian Pop wrote:
On Thu, Jun 30, 2011 at 10:03, Richard Guenther wrote:
But what do you do for
for (unsigned char i = 128; i< 255; ++i)
? You change 128 to -128 which is wrong.
Yes, 128 gets translated to -128.
And 255 gets translated to -1.
And so the loop i
On 07/07/2011 08:07 PM, Sebastian Pop wrote:
Hi,
Hi Sebastian,
sorry for taking so long. Here some comments from me:
First there are two cleanup patches independent of the fix:
Start counting nesting level from 0.
Do not compute twice type, lb, and ub.
Then the patch that fixes PR476
On 07/17/2011 07:55 AM, Sebastian Pop wrote:
Hi Tobias,
On Sat, Jul 16, 2011 at 20:02, Tobias Grosser wrote:
Here I am a little lost. You write using the precise method you get an
interval [0,99] for the example in vect-pr43423.c. This is the example:
int a[100], b[100], c[100];
void foo
On 07/18/2011 05:03 PM, Sebastian Pop wrote:
On Sun, Jul 17, 2011 at 19:41, Tobias Grosser wrote:
Accessing a[100] is undefined in C, so i<100, and so n<= 100.
Sure. I am just surprised we already include this information in graphite.
Do we add this to the context?
Yes, that'
On 07/18/2011 07:07 PM, Sebastian Pop wrote:
On Mon, Jul 18, 2011 at 11:11, Tobias Grosser wrote:
We introduce casts when we generate code for an expression with a type
smaller than the types of its constituents.
So the next question is: What is the type of the expression. As far as I
On 07/19/2011 12:33 AM, Sebastian Pop wrote:
On Mon, Jul 18, 2011 at 16:40, Tobias Grosser wrote:
You are right. In case we want to downcast b we would also need to prove
that b itself fits into the smaller type. (This may happen, if the larger
type was introduced earlier to remove casts, but
On 07/21/2011 06:09 PM, Sebastian Pop wrote:
Hi,
On Thu, Jul 21, 2011 at 07:37, Rainer Orth
wrote:
As described in the PR, the use of LANGUAGE_C in CLooG breaks C++
bootstrap on IRIX 6.5. Both MIPS and Alpha C compilers predefine
LANGUAGE_C themselves, which clashes with the CLooG macro in
.
On 07/21/2011 08:31 PM, Sebastian Pop wrote:
Hi,
This patch-set addresses the comments from Tobias on fixing PR47654.
The first patches are cleanups:
- Start counting nesting level from 0 and use the standard "Polyhedral
SCattering Transformed" psct_* interface.
- Do not compute twice typ
latest one. Because we expect that most users
would need an update, and, as we will soon use some of the newer features, there
is no need to force another update later.
Tobias Grosser (3):
Make CLooG isl the only supported CLooG version.
Require cloog 0.16.3
Remove code that supported le
2011-07-21 Tobias Grosser
* configure: Regenerated.
* configure.ac: Require cloog isl 0.16.3
---
ChangeLog|5 +
configure|6 +++---
configure.ac |2 +-
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index a08a780
2011-07-21 Tobias Grosser
* configure: Regenerated.
* config/cloog.m4: Remove support for CLooG-ppl and CLooG-parma,
both cloog.org and legacy versions. The only supported version will
be CLooG with the isl backend.
---
ChangeLog |7 ++
config
2011-07-21 Tobias Grosser
* configure: Regenerated.
* config/cloog.m4: Do not define CLOOG_ORG
and in gcc/
2011-07-21 Tobias Grosser
* Makefile.in (graphite-clast-to-gimple.o, graphite-cloog-util.o):
Remove graphite-cloog-util.h.
* graphite-clast
On 07/22/2011 01:46 AM, Sebastian Pop wrote:
On Thu, Jul 21, 2011 at 18:00, Tobias Grosser wrote:
static void
create_params_index (htab_t index_table, CloogProgram *prog) {
- CloogNames* names = cloog_program_names (prog);
- int nb_parameters = cloog_names_nb_parameters (names);
- char
On 07/22/2011 10:08 AM, Richard Guenther wrote:
On Fri, Jul 22, 2011 at 1:00 AM, Tobias Grosser wrote:
Hi,
I propose to switch to the official cloog.org cloog version with isl backend and
at the same time to remove support for both CLooG-PPL legacy as well as
CLooG-Parma.
We want to switch
On 07/26/2011 08:30 PM, Sebastian Pop wrote:
On Fri, Jul 22, 2011 at 07:32, Joseph S. Myers wrote:
On Fri, 22 Jul 2011, Tobias Grosser wrote:
I propose to switch to the official cloog.org cloog version with isl backend and
at the same time to remove support for both CLooG-PPL legacy as well
On 07/27/2011 06:20 PM, Jack Howarth wrote:
On Fri, Jul 22, 2011 at 01:00:09AM +0200, Tobias Grosser wrote:
Hi,
I propose to switch to the official cloog.org cloog version with isl backend and
at the same time to remove support for both CLooG-PPL legacy as well as
CLooG-Parma.
We want to
On 07/24/2011 08:25 AM, Sebastian Pop wrote:
2011-07-23 Sebastian Pop
PR middle-end/47653
* graphite-scop-detection.c (graphite_can_represent_loop): Discard
loops using wrapping semantics.
* gcc.dg/graphite/run-id-pr47653.c: New.
* gcc.dg/graphite/interc
On 07/23/2011 12:01 AM, Sebastian Pop wrote:
The CLAST produced by CLooG-ISL contains an assignment and GCC chokes
on it. The exact CLAST contains an assignment followed by an if:
scat_1 = max(0,ceild(T_4-7,8));
if (scat_1<= min(1,floord(T_4-1,8))) {
S7(scat_1);
}
This is equivalent to a lo
On 07/28/2011 06:56 PM, Sebastian Pop wrote:
Hi Tobi,
On Thu, Jul 28, 2011 at 12:13, Tobias Grosser wrote:
+ struct clast_user_stmt *body
+= clast_get_body_of_loop ((struct clast_stmt *) stmt);
I am not a big fan of using clast_get_body_of_loop as it is buggy.
Introducing new uses of
101 - 170 of 170 matches
Mail list logo
