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 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 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/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 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/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 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 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 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 09/29/2015 10:19 PM, Aditya Kumar wrote:
From: hiraditya
No functional changes intended. Passes make check and bootstrap.
LGTM.
Tobias
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/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/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/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 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/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/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 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 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/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 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 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/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/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
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(-)
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-
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
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/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 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 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 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 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 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 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 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 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/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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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 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
LGTM.
Cheers,
Tobias
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
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 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 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 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 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 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 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 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 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 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 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);
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 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
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 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 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:
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 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 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 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 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 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 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 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 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 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 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?
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 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
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 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 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 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 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 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 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 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 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
1 - 100 of 170 matches
Mail list logo