On 07/17/2015 12:23 AM, Sebastian Pop wrote:
This fixes bootstrap of GCC with BOOT_CFLAGS="-g -O2 -fgraphite-identity
-floop-nest-optimize -floop-block -floop-interchange -floop-strip-mine".
It passes regstrap on amd64-linux.
Ok to commit to trunk?
Very nice.
this but seems to include multip
On 07/17/2015 12:35 AM, Sebastian Pop wrote:
gcc/ChangeLog:
2015-07-16 Aditya Kumar
Sebastian Pop
* common.opt (floop-fuse): New.
* doc/invoke.texi (floop-fuse): Documented.
* graphite-optimize-isl.c (optimize_isl): Use
ISL_SCHEDULE_FUSE
p-mine" } */
+
+typedef struct m {
+ char *A;
+ char *B;
+} mystruct;
+mystruct arr[52];
+
+void main () {}
+void generateICE (void)
+{
+ int i;
+ for (i=0; i<52; i++)
+{
+ arr[i].A = "";
+ arr[i].B = 0;
+}
+}
--
2.1.0.243.g30d45f7
-Original Message-
Hi Aditya,
could you possible expand the commit message a little bit to explain
what you are doing?
Tobias
On 07/18/2015 01:00 AM, Aditya Kumar wrote:> ---
gcc/graphite-isl-ast-to-gimple.c | 153 +++
1 file changed, 122 insertions(+), 31 deletions(-)
On 07/19/2015 09:46 PM, Aditya Kumar wrote:
Refactor graphite-isl-ast-to-gimple.c:
Refactor so that each function can access 'region'. This will help
maintain a parameter rename_map within a region. No functional change intended.
This patch will be followed by another set of patches
where transla
On 07/19/2015 11:10 PM, james harvey wrote:
These two patches appear to do the trick. I'm building with ISL 0.15
just fine now.
Nice.
Tobias
On 07/20/2015 06:24 PM, Aditya Kumar wrote:
From: Aditya Kumar
Refactor graphite-isl-ast-to-gimple.c:
Refactor so that each function can access 'region'. This will help
maintain a parameter rename_map within a region. No functional change intended.
This patch will be followed by another set of
On 07/25/2015 12:36 AM, Sebastian Pop wrote:
When trying to analyze why Graphite does not handle a loop nest, it is easy to
look in the dumps of -fdump-tree-graphite-all to guess what has to be changed to
catch the loop. This patch makes the dumps a bit more verbose and useful.
---
gcc/graphit
On 09/25/2015 10:39 PM, Sebastian Pop wrote:
The patch makes the detection of scop parameters in parameter_index_in_region a
bit more conservative by discarding scalar variables defined in function of data
references defined in the scop.
2015-09-25 Aditya Kumar
Sebastian Pop
On 09/28/2015 03:30 AM, Aditya Kumar wrote:
From: hiraditya
Redesign Graphite scop detection for faster compiler time and detecting more
SCoPs.
Existing algorithm for SCoP detection in graphite was based on dominator tree
where a tree (CFG) traversal was required for analyzing an SESE. The tr
On 09/29/2015 06:26 PM, Sebastian Pop wrote:
This code is not used anymore after we removed the previous loop optimizer (not
based on the ISL scheduler.) We will add back the detection of commutative
reductions after we improve the code generation of scalar dependences (by not
going out of SSA f
On 09/29/2015 10:19 PM, Aditya Kumar wrote:
From: hiraditya
No functional changes intended. Passes make check and bootstrap.
LGTM.
Tobias
On 09/30/2015 12:10 AM, Sebastian Pop wrote:
This patch fixes PR66754 by reverting an earlier unintended change.
We now generate a much simpler AST for interchange-1.c:
ISL AST generated by ISL:
{
for (int c1 = 0; c1 <= 1334; c1 += 1) {
S_7(c1);
for (int c3 = 0; c3 <= 1334; c3 += 1)
On 10/01/2015 12:11 AM, Sebastian Pop wrote:
Before our rewrite of the scop detection, we used to not have a valid SESE
region under hand, and so we used to do more ad-hoc analysis of data references
by trying to prove that at all levels of a loop nest the data references would
be still valid.
N
On 10/01/2015 06:31 PM, Sebastian Pop wrote:
create mode 100644 gcc/testsuite/gcc.dg/graphite/scop-pr66980.c
diff --git a/gcc/graphite-scop-detection.c b/gcc/graphite-scop-detection.c
LGTM.
Tobias
On 10/01/2015 11:23 PM, Aditya Kumar wrote:
From: hiraditya
Use sese_l throughout SCoP detection and create vec at the very end when
all SCoPs have been identified. 'struct sese_l' is very lightweight (two
pointers) compared to 'struct scop'.
No functional change intended. Passes regtest and b
On 10/01/2015 10:36 PM, Aditya Kumar wrote:
From: hiraditya
Renaming gimple_bb to gimple_poly_bb because there is a function gimple_bb
by the same name in gimple.h. No functional change intended.
Passes regtest and bootstrap.
LGTM
Tobias
On 10/02/2015 06:54 AM, Aditya Kumar wrote:
From: hiraditya
Outlined functions from stmt_simple_for_scop_p. No functional changes intended.
Passes regtest and bootstrap.
gcc/ChangeLog:
2015-10-01 Aditya Kumar
* graphite-scop-detection.c (stmt_has_side_effects): New function
On October 2, 2015 10:44:00 PM GMT+01:00, Sebastian Pop
wrote:
>---
> gcc/params.def | 2 +-
> gcc/testsuite/gcc.dg/graphite/scop-sor.c | 3 +--
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
>diff --git a/gcc/params.def b/gcc/params.def
>index 3f91992..da2c6a3 10064
On 10/06/2015 05:45 PM, Sebastian Pop wrote:
2015-10-05 Aditya Kumar
Sebastian Pop
* graphite-dependences.c (scop_get_transformed_schedule):
Remove.
(no_violations): Remove.
(subtract_commutative_associative_deps): Remove.
On 10/06/2015 10:45 PM, Sebastian Pop wrote:
2015-10-06 Aditya Kumar
Sebastian Pop
* graphite-poly.c (new_poly_dr): Remove dr_base_object_set.
Do not set PDR_BASE_OBJECT_SET.
* graphite-poly.h (poly_dr): Same.
On 07/08/2014 15:18, Roman Gareev wrote:
To commit 2), I would like you to run a wider set of tests (e.g., the LLVM
test suite). If this passes successful, we should give a headsup on the GCC
mailing list and ask other people to try the new isl support.
If now bugs have found, we switch.
I've t
On 08/08/2014 15:11, Roman Gareev wrote:
I think this is fine. On the other side, I think the test case itself
>is unnecessarily large. I would assume the majority of the code could
>be deleted while still triggering the bug. Could you give it a shot.
I've attached an improved version of the pat
On 09/08/2014 09:42, Roman Gareev wrote:
Is this segmentation fault at compile time or at run-time? I believe it was
a segfault at run-time due to a miscompile.
Yes, it's a segfault at run-time. These source codes produce wrong object files.
Possibly. Can you split the .cpp files such that yo
On 09/08/2014 12:05, Roman Gareev wrote:
With just C++ code, Sven can help little. He has no knowledge about graphite
internals.
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 wher
On 11/08/2014 09:11, Roman Gareev wrote:
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?
I’ve manually selected parts of code, which produce the scope.
I’ve found out that this bug i
On August 12, 2014 8:15:34 AM CEST, Roman Gareev wrote:
>> Checking for this specific AST may cause failures with future
>versions of
>> isl that choose a different schedule. Could you write a regular
>expression
>> that checks that there is no if-condition contained in a for loop? I
>think
>> thi
On 13/08/2014 16:07, 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
(TYPE_PTRMEM_P is true for it), the type is a pointer type, and the
pointee is not a data member (TYPE_PTR_P is true f
On 16/08/2014 13:28, Roman Gareev wrote:
Richard, could you please review these patches? We would be very glad
for your comments.
P.S: I’ve attached an improved ChangeLog_entry.
The patch and changelog looks good to me, but we still need a
non-graphite reviewer oking the changes.
Tobias
On 18/06/2014 21:00, Roman Gareev wrote:
These patches add ISL AST generation to graphite, which can be chosen
by the fgraphite-code-generator=[isl|cloog] switch. The first patch
makes initial renaming of gloog and gloog_error to
graphite_regenerate_ast_cloog and graphite_regenerate_error,
respec
Thanks Sebastian for the review! It is good to see you again on the
mailing list!
On 23/06/2014 11:29, Sebastian Pop wrote:
Please add a FIXME note in graphite_regenerate_ast_isl saying that
this is not yet a full implementation of the code generator with ISL
ASTs.
It would be useful to make th
tch (not bootstrapped yet), that should fix the
issue. I will start a gcc (non-graphite) bootstrap to see if it works
and will commit it immediately after.
Please report back if it fixes the bootstrap for you.
Cheers,
Tobias
>From 2910e41368c3895a7a023133a1fcb87772b838a8 Mon Sep 17 00:00:
gcc/ChangeLog
@@ -1,3 +1,7 @@
+2014-06-29 Tobias Grosser
+
+ * graphite-isl-ast-to-gimple.c: Add missing guards.
+
2014-06-29 Roman Gareev
* Makefile.in:
diff --git a/gcc/graphite-isl-ast-to-gimple.c b/gcc/graphite-isl-ast-to-gimple.c
index 6437474..8ba7b75 100644
--- a/gcc/graphite-isl-ast
On 05/07/2014 08:58, Roman Gareev wrote:
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?
The ChangeLog should be per-function. Otherwise LGTM.
Tobias
On 07/07/2014 00:16, Mircea Namolaru wrote:
Hello,
In the isl library used by Graphite, isl_val replaced isl_val (that become
obsolete).
This patch implements the required changes in Graphite.
No regressions for c/c++/fortran on x86-64 Linux.
Hi Mircea,
the patch looks good and the directi
On 05/29/2015 06:54 PM, Bernhard Reutner-Fischer wrote:
Hi,
config/ChangeLog:
2015-05-29 Bernhard Reutner-Fischer
* isl.m4 (ISL_CHECK_VERSION): AC_SUBST ENABLE_ISL_CHECK and set
gcc_cv_isl. Tidy whitespace. Lowercase first line of help-text
like for all the other he
On 26.11.2014 16:55, Tobias Burnus wrote:
This patch adds a configure check for isl_schedule_constraints_compute_schedule,
which is new in ISL 0.13 - and uses it for conditional compilation.
The graphite*c patch is based on the one of Jack Howarth,
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg0
On 26.11.2014 17:27, Tobias Burnus wrote:
On Wed, Nov 26, 2014 at 04:55:40PM +0100, Tobias Burnus wrote:
This patch adds a configure check for isl_schedule_constraints_compute_schedule,
which is new in ISL 0.13 - and uses it for conditional compilation.
Repeating the test on a massively multic
On 04/01/2015 05:09 PM, Bernhard Reutner-Fischer wrote:
Hi,
Trying to build config-list.mk for current trunk.
The box is a stable debian (7.8 it seems) so the OS' ISL is too old
thus i was attempting to use in-tree ISL.
When using an in-tree ISL gcc attempts to determine if it is recent
enough
On 06/25/2015 04:27 PM, Sebastian Pop wrote:
On Thu, Jun 25, 2015 at 5:00 AM, Richard Biener
wrote:
Yes, it looks good. What about COMPLEX_CST and VECTOR_CST and
their types?
The question came around also when we were looking at these problems:
we really only care for integer_cst constants (
On 06/30/2015 02:09 AM, Sebastian Pop wrote:
On Mon, Jun 29, 2015 at 3:04 PM, Aditya Kumar wrote:
In this patch we discard the scops where entry and exit are the same BB.
This is an effort to remove graphite-scop-detection.c:limit_scops.
Removing the limit_scops function introduces correctness
On 06/30/2015 02:12 AM, Sebastian Pop wrote:
On Mon, Jun 29, 2015 at 3:58 PM, Aditya Kumar wrote:
No regressions.
2015-06-29 Aditya Kumar
Sebastian Pop
* graphite-scop-detection.c (stmt_simple_for_scop_p): Bail out in case
of a return statement.
Looks good to me.
On 06/30/2015 10:50 PM, Aditya Kumar wrote:
No regressions.
2015-06-29 Aditya Kumar
Sebastian Pop
* graphite-scop-detection.c (stmt_simple_for_scop_p): Bail out in case
of a return statement.
LGTM.
Tobias
On 06/30/2015 05:47 PM, Aditya K wrote:
Hi Tobias,
A test case (gcc/testsuite/gcc.dg/graphite/pr18792.c) came up when we removed
`graphite-scop-detection.c:limit_scops'.
The test case is a scop where entry==exit,
BB5 (*#) -> BB6 (#);
BB6 -> BB5;
In this case BB2 is out of the scop. This is bas
On 07/02/2015 05:37 PM, Aditya K wrote:
A test case (gcc/testsuite/gcc.dg/graphite/pr18792.c) came up when we removed
`graphite-scop-detection.c:limit_scops'.
The test case is a scop where entry==exit,
BB5 (*#) -> BB6 (#);
BB6 -> BB5;
In this case BB2 is out of the scop. This is basically an e
On 07/02/2015 06:52 PM, Aditya Kumar wrote:
gcc/ChangeLog:
2015-07-02 Aditya Kumar
Sebastian Pop
* graphite-sese-to-poly.c (rewrite_cross_bb_scalar_deps):
Point iterator to use_stmt.
Hi Aditya,
this patch does not explain what was wrong and why this change
On 07/02/2015 08:34 PM, Sebastian Pop wrote:
On Thu, Jul 2, 2015 at 1:17 PM, Tobias Grosser wrote:
On 07/02/2015 06:52 PM, Aditya Kumar wrote:
gcc/ChangeLog:
2015-07-02 Aditya Kumar
Sebastian Pop
* graphite-sese-to-poly.c (rewrite_cross_bb_scalar_deps
On 07/02/2015 09:03 PM, Sebastian Pop wrote:
On Thu, Jul 2, 2015 at 1:44 PM, Tobias Grosser wrote:
If you git log grep for this commit, you would see that this patch
reverts this "typo" introduced in a very large patch.
Sure. The corresponding change was:
- gimple_stmt_it
On 07/02/2015 09:09 PM, Sebastian Pop wrote:
On Thu, Jul 2, 2015 at 2:03 PM, Ramana Radhakrishnan
wrote:
How about a testcase or 2 or mentioning if it is covered by existing
testcases ?
The patch fixes a test in testsuite/gcc.dg/graphite/ when removing the
use of limit_scops().
Maybe the comm
On 09.11.2014 18:16, Roman Gareev wrote:
Hi Tobias,
I've attached a patch which removes using of CLooG library from
Graphite. Is it fine for trunk?
The patch looks great. The only piece I think we missed is the
fgraphite-code-generator flag. I would propose to remove it as well in
this commi
On 09.11.2014 18:35, Tobias Burnus wrote:
Roman Gareev wrote:
* Makefile.in: Remove the compilation of graphite-clast-to-gimple.o.
* graphite.c: Remove using of CLooG.
* graphite-blocking.c: Likewise.
* graphite-dependences.c: Likewise.
* graphite-poly.c: Likewise.
* grap
On 10.11.2014 10:03, Roman Gareev wrote:
The patch looks great. The only piece I think we missed is the
fgraphite-code-generator flag. I would propose to remove it as well in this
commit, as it does not have any effect any more.
In this case, we’ll also have to change tests which use
fgraphite-
On 10.11.2014 20:14, Roman Gareev wrote:
Sure. We should drop the flag in these test cases.
This seems to make sense, as they now test something different and the flag
removal would reflect this.
I personally would include this in the same patch. Would this be difficult?
I don’t think that it
On 11.11.2014 14:01, Tobias Burnus wrote:
Now that CLooG is no longer used by GCC, it makes sense to also remove it from
the main configure file. Especially as the in-tree build currently only works
if also CLooG is available.
Build on x86-64-gnu-linux - and tested that Graphite still works.*
OK
On 08/12/2015 10:33 PM, Aditya Kumar wrote:
Passes bootstrap, no regressions.
With this patch gcc bootstraps with graphite.
make BOOT_CFLAGS="-g -O2 -fgraphite-identity -floop-interchange -floop-block"
LGTM, but please use a longer sentence to explain what you do.
Tobias
On 08/17/2015 10:30 PM, Aditya Kumar wrote:
From: Aditya Kumar
Changing the type of scop::region from void* to sese, as this is
the only type assigned to scop::region for now. No functional changes intended.
Passes regtest and bootstrap.
LGTM.
Tobias
On 08/27/2015 12:14 AM, Sebastian Pop wrote:
Hi,
Richi suggested at the Cauldron that it would be good to have graphite more
automatic and with fewer flags. The first patch removes the -funroll-and-jam
pass that does not seem very stable or useful for now. The second patch removes
the other -f
On 09/03/2015 12:34 AM, Sebastian Pop wrote:
2015-09-02 Sebastian Pop
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac (HAVE_ISL_CTX_MAX_OPERATIONS): Detect.
* graphite-optimize-isl.c (optimize_isl): Stop computation when
On 09/05/2015 12:57 AM, Aditya Kumar wrote:
This patch removes graphite-scop-detection.c:limit_scops function and fix
related issues arising because of that. The functionality limit_scop was added
as an intermediate step to discard the loops which graphite could not
handle. Removing limit_scop re
On 09/11/2015 07:07 PM, Aditya Kumar wrote:
Updated patch with corrections:
Refactor graphite-optimize-isl.c. Renamed function name, variable names etc.,
and indented the source according to gcc style guidelines. Modified comments
accordingly. No functional change intended.
Looks reasonable.
On 09/11/2015 07:29 PM, Aditya Kumar wrote:
The variable `static bool enable_polly_vector' is always assigned to false.
This results in dead code in optimize-isl.c.
Removing the dead code. No functional change intended.
Fine with me as well. This code is used in Polly to enable outer loop
vec
On Sun, Dec 2, 2012, at 02:42 AM, Lawrence Crowl wrote:
> Change graphite-related hash tables from htab_t to hash_table:
>
> graphite-clast-to-gimple.c ivs_params::newivs_index
> graphite-clast-to-gimple.c ivs_params::params_index
> graphite-clast-to-gimple.c print_generated_program::params_index
ite/pr54094.c
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 1bcd994..bdc674d 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,12 @@
+2013-07-13 Tobias Grosser
+
+ PR tree-optimization/54094
+ * graphite-clast-to-gimple.c (translate_clast_for_loop): Derive the
+ scheduling dimension
On 02/09/2014 04:47 PM, Mircea Namolaru wrote:
Patch for replacement of the isl_int (obsolete) by isl_val.
No regressions for c/c++/fortran on x86-64 Linux.
Hi Mircae,
thanks a lot for looking into this.
Just for people not aware of the idea of this patch. Cloog recently
upgraded to t
On 02/10/2014 04:12 AM, Richard Biener wrote:
On Sun, Feb 9, 2014 at 9:19 PM, Tobias Grosser wrote:
On 02/09/2014 04:47 PM, Mircea Namolaru wrote:
Patch for replacement of the isl_int (obsolete) by isl_val.
No regressions for c/c++/fortran on x86-64 Linux.
Hi Mircae,
thanks a
On 02/26/2014 03:30 PM, Mircea Namolaru wrote:
This patch fixes the libgomp problems:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58028
2014-02-26 Tobies Grosser
Mircea Namolaru
Hi Mircea,
the patch is correct.
Fix for bug 58028
* graphite-clast-to-gimple.c (set_cloog_options):
Don't remo
On 02/26/2014 10:09 PM, Mircea Namolaru wrote:
This patch fixes the libgomp problems:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58028
2014-02-26 Tobias Grosser
Mircea Namolaru
Fix for bug 58028
* graphite-clast-to-gimple.c (set_cloog_options):
Don't remove scalar dimensions
Index
On 03/03/2014 12:39 PM, Richard Biener wrote:
On Fri, Feb 28, 2014 at 8:37 PM, Mircea Namolaru
wrote:
Hi,
Thanks. Here is the updated patch.
Boostrapped / tested on x86_64-unknown-linux-gnu and applied.
Thanks Richard!
Tobias
On 08/07/2014 14:52, Roman Gareev wrote:
The ChangeLog should be per-function. Otherwise LGTM.
I've fixed this.
OK, LGTM then.
Tobias
On 08/07/2014 14:47, Roman Gareev wrote:
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 j
I tried to incorporate all your comments in the attached patch.
Nice. It looks now very good to me. One final and last detail:
+/* TREE_FROM_ISL_ID maps ISL's scattering and parameter identifiers
+ to corresponding trees. */
+
+typedef struct ivs_params {
+ std::map tree_from_isl_id;
+} *i
On 11/07/2014 13:11, Roman Gareev wrote:
The struct now contains only a single element such that there seems to be no
need for it anymore. Should we remove it? (We could still use a typedef if
you believe the datatype is too long).
I don't mind removing it. However I think that we should choose
On 11/07/2014 15:41, Roman Gareev wrote:
I've attached an improved version of the patch and the ChangeLog
entry. Are they fine for trunk?
LGTM.
Thank you!
Tobias
On 12/07/2014 14:18, Roman Gareev wrote:
I've attached the patch, which contains generation of Gimple code from
isl_ast_node_user.
I think that it would be better to add motivation for the following
line from the original source:
if (GBB_BB (gbb) == ENTRY_BLOCK_PTR_FOR_FN (cfun))
{
isl_
On 13/07/2014 12:34, Roman Gareev wrote:
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.
Roman, this patch is OK to commit, but please include a correct
changelog file.
Tobias
On 15/07/2014 17:02, Roman Gareev wrote:
I'm seeing the error:
gcc/graphite-isl-ast-to-gimple.c:31:25: warning: isl/val_gmp.h: No such file
or directory
when building for aarch64.
isl/val_gmp.h is included in 0.12 AFAICS so perhaps we should demand 0.12
instead of 0.11 ?
According to isl's C
On 15/07/2014 16:59, Roman Gareev wrote:
>> >This is a pure style change which seems unrelated. Also, is the
original
>line really too long? I may have miscounted, but it seems to fit
>exactly.
If I am not mistaken, lines should be limited to 80 characters,
according to conventions, which are m
On 16/07/2014 11:36, Richard Biener wrote:
On Tue, Jul 15, 2014 at 5:34 PM, Tobias Grosser wrote:
On 15/07/2014 17:02, Roman Gareev wrote:
I'm seeing the error:
gcc/graphite-isl-ast-to-gimple.c:31:25: warning: isl/val_gmp.h: No such
file
or directory
when building for aarch64.
On 16/07/2014 14:03, Roman Gareev wrote:
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?
isl 0.12.2 is always compiled with GMP support. Only for the unreleased
isl-0.14 imath was intr
On 17/07/2014 16:11, Roman Gareev wrote:
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?
I am not aware of any problems with isl 0.12 and would be surprised if
such problems exist. Are you?
The patch its
On 17/07/2014 16:08, Roman Gareev wrote:
I see. Could you use vec_safe_grow_cleared(iv_map, loop_num) instead?
>This shows probably better that you zero initialize the vector.
If I am not mistaken, vec_safe_grow_cleared has the following declaration:
vec_safe_grow_cleared (vec *&v, unsigned len
One last question:
On 18/07/2014 12:28, Roman Gareev wrote:
+ iv_map.create (loop->num + 1);
+ iv_map.safe_grow_cleared (loop->num + 1);
One of these two seems redundant.
Cheers,
Tobias
On 18/07/2014 12:34, Roman Gareev wrote:
I suggest you use the largest available integer mode via
>mode = mode_for_size (MAX_FIXED_MODE_SIZE, MODE_INT, 0);
>type = build_nonstandard_integer_type (GET_MODE_PRECISION (mode), [01]);
Thank you for the suggestion!
>Roman, can you give this a shot?
On July 20, 2014 1:39:08 PM CEST, Roman Gareev wrote:
>This patch fixes a formatting issue related to the number of
>characters in the line. Is it fine for trunk?
Yes.
That's an obvious fix. In case you feel a patch is obvious and it only touches
graphite. Feel free to commit directly and to
On July 20, 2014 1:29:30 PM CEST, Roman Gareev wrote:
>> I am not aware of any problems with isl 0.12 and would be surprised
>if such
>> problems exist. Are you?
>
>I'm not aware of them, too.
>
>> P.S: As Richard suggested, we may also want to forbid CLooG 0.17.
>
>I've attached the patch, whic
On 21/07/2014 10:25, Roman Gareev wrote:
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?
Fine with me. Please post a question on gcc devel to see if someone can
explain us t
On 21/07/2014 12:25, Roman Gareev wrote:
I've asked the community about this.
The patch below contains the FIXME.
LGTM. Feel free to commit.
Thanks,
Tobias
On 22/07/2014 18:00, Roman Gareev wrote:
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 Garee
On 22/07/2014 18:00, Roman Gareev wrote:
I've attached the patch, which contains generation of Gimple code from
isl_ast_node_block. Is it fine for trunk?
LGTM.
Tobias
On 23/07/2014 11:13, Rainer Orth wrote:
Roman Gareev writes:
I've attached the patch, which contains generation of Gimple code from
isl_ast_node_block. Is it fine for trunk?
2014-07-22 Roman Gareev
gcc/
* graphite-isl-ast-to-gimple.c:
(translate_isl_ast_node_block
On 23/07/2014 16:55, Roman Gareev wrote:
I've attached the patch, which adds handling of isl_ast_op_pdiv_q and
isl_ast_op_pdiv_r. It also contains a corresponding test case, which
generates the following ISL AST:
{
for (int c1 = 0; c1 < -((-k.0 + i + 4294967296) % 4294967296) +
4294967296; c1
On 23/07/2014 16:55, Roman Gareev wrote:
If we try to generate code from the following ISL AST:
{
for (int c1 = 0; c1 < k.3; c1 += 1) {
S_21(c1);
S_21(c1);
S_4(c1);
for (int c3 = 0; c3 < pretmp; c3 += 1)
S_5(c1, c3);
S_7(c1);
S_26(c1);
S_8(c1);
S
On 24/07/2014 12:09, Roman Gareev wrote:
Any reason you don't make 'k' a function parameter?
Yes, ISL'll generate the following code, if 'k' a function parameter:
for (int c1 = 0; c1 <= 24; c1 += 1)
S_3(c1);
However, we could use -fno-ipa-cp to get the ISL AST, which contains
isl_ast_op_p
On 24/07/2014 12:09, Roman Gareev wrote:
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.
LGTM.
Tobias
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)
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:
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
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 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
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);
1 - 100 of 170 matches
Mail list logo
