Re: [PATCH] remove dead code used by the old cloog scheduler

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.

Re: [PATCH 1/3] remove dead code in computation of alias sets

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. *

Re: [PATCH 3/3] increase the number of parameters

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

Re: [PATCH] outline functions from stmt_simple_for_scop_p

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

Re: [PATCH 2/2] call scev analysis in scop-detection as in sese-to-poly

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.

Re: [PATCH] correctly handle non affine data references

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

Re: [PATCH] use sese_l throughout scop-detection

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.

Re: [PATCH] Rename gimple_bb to gimple_poly_bb

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

Re: [PATCH] remove dead code of commutative_reductions

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

Re: [PATCH] Make compute_deps, extend_schedule static

On 09/29/2015 10:19 PM, Aditya Kumar wrote: From: hiraditya No functional changes intended. Passes make check and bootstrap. LGTM. Tobias

Re: [PATCH] use MIN fusion for ISL-14

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 +=

Re: [Graphite] Redesign Graphite scop detection

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

Re: [PATCH] fix PR67700

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

Re: [PATCH] Refactor optimize isl

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.

Re: [PATCH] Remove dead code from graphite-optimize-isl.c

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

Re: [PATCH] [graphite] Remove limit_scops

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: [PATCH] fix PR53852: stop ISL after a given number of operations

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

Re: [PATCH 0/2] Final cleanup in move to ISL

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

Re: [PATCH] Specify the type of scop-region

On 08/17/2015 10:30 PM, Aditya Kumar wrote: From: Aditya Kumar aditya...@samsung.com 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

Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE

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

Re: [PATCH] [graphite] dump reasons why graphite failed to detect a scop

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. ---

Re: [PATCH] Refactor graphite-isl-ast-to-gimple.c

On 07/20/2015 06:24 PM, Aditya Kumar wrote: From: Aditya Kumar hiradi...@msn.com 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

Re: [PATCH] gcc/: Fix building with isl-0.15.0; includes

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

Re: [PATCH] Refactor graphite-isl-ast-to-gimple.c

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

Re: [PATCH] [graphite] fix pr61929

-strip-mine } */ + +typedef struct m { + char *A; + char *B; +} mystruct; +mystruct arr[52]; + +void main () {} +void generateICE (void) +{ + int i; + for (i=0; i52; i++) +{ + arr[i].A = ; + arr[i].B = 0; +} +} -- 2.1.0.243.g30d45f7 -Original Message- From: Tobias

Re: [PATCH] Rename parameters which are within scop

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(-)

Re: [PATCH] enable loop fusion with ISL scheduler

On 07/17/2015 12:35 AM, Sebastian Pop wrote: gcc/ChangeLog: 2015-07-16 Aditya Kumar aditya...@samsung.com Sebastian Pop s@samsung.com * common.opt (floop-fuse): New. * doc/invoke.texi (floop-fuse): Documented. * graphite-optimize-isl.c

Re: [PATCH] [graphite] fix pr61929

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

Re: [PATCH] Discard Scops for which entry==exit

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

Re: [PATCH] Graphite cannot handle return stmt

On 06/30/2015 10:50 PM, Aditya Kumar wrote: No regressions. 2015-06-29 Aditya Kumar aditya...@samsung.com Sebastian Pop s@samsung.com * graphite-scop-detection.c (stmt_simple_for_scop_p): Bail out in case of a return statement. LGTM. Tobias

Re: [PATCH] Discard Scops for which entry==exit

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

Re: [PATCH] Restore previous change for gimple_phi_iterator

On 07/02/2015 06:52 PM, Aditya Kumar wrote: gcc/ChangeLog: 2015-07-02 Aditya Kumar aditya...@samsung.com Sebastian Pop s@samsung.com * graphite-sese-to-poly.c (rewrite_cross_bb_scalar_deps): Point iterator to use_stmt. Hi Aditya, this patch does not

Re: [PATCH] Restore previous change for gimple_phi_iterator

On 07/02/2015 08:34 PM, Sebastian Pop wrote: On Thu, Jul 2, 2015 at 1:17 PM, Tobias Grosser tob...@grosser.es wrote: On 07/02/2015 06:52 PM, Aditya Kumar wrote: gcc/ChangeLog: 2015-07-02 Aditya Kumar aditya...@samsung.com Sebastian Pop s@samsung.com * graphite

Re: [PATCH] Restore previous change for gimple_phi_iterator

On 07/02/2015 09:03 PM, Sebastian Pop wrote: On Thu, Jul 2, 2015 at 1:44 PM, Tobias Grosser tob...@grosser.es 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

Re: [PATCH] Restore previous change for gimple_phi_iterator

On 07/02/2015 09:09 PM, Sebastian Pop wrote: On Thu, Jul 2, 2015 at 2:03 PM, Ramana Radhakrishnan ramana@googlemail.com 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

Re: [PATCH] Discard Scops for which entry==exit

On 06/30/2015 02:09 AM, Sebastian Pop wrote: On Mon, Jun 29, 2015 at 3:04 PM, Aditya Kumar hiradi...@msn.com 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

Re: [PATCH] Graphite cannot handle return stmt

On 06/30/2015 02:12 AM, Sebastian Pop wrote: On Mon, Jun 29, 2015 at 3:58 PM, Aditya Kumar hiradi...@msn.com wrote: No regressions. 2015-06-29 Aditya Kumar aditya...@samsung.com Sebastian Pop s@samsung.com * graphite-scop-detection.c (stmt_simple_for_scop_p): Bail

Re: [PATCH] Do not constrain on REAL_TYPE

On 06/25/2015 04:27 PM, Sebastian Pop wrote: On Thu, Jun 25, 2015 at 5:00 AM, Richard Biener richard.guent...@gmail.com 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

Re: [PATCH, v2] Fix bootstrap with in-tree ISL

On 05/29/2015 06:54 PM, Bernhard Reutner-Fischer wrote: Hi, config/ChangeLog: 2015-05-29 Bernhard Reutner-Fischer al...@gcc.gnu.org * isl.m4 (ISL_CHECK_VERSION): AC_SUBST ENABLE_ISL_CHECK and set gcc_cv_isl. Tidy whitespace. Lowercase first line of help-text like

Re: [PATCH, CFT] Fix bootstrap with in-tree ISL

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

Re: [Build, Graphite] PR64017 - support ISL-0.14 (gcc/configure.ac and gcc/graphite*.c)

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,

Re: [Build, Graphite] PR64017 - support ISL-0.14 (gcc/configure.ac and gcc/graphite*.c)

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

Re: [Build, patch] Remove CLooG from the main configure.ac

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.*

Re: RFC: Update ISL under gcc/infrastructure/ ? // Remove CLooG?

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

Re: RFC: Update ISL under gcc/infrastructure/ ? // Remove CLooG?

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

Re: RFC: Update ISL under gcc/infrastructure/ ? // Remove CLooG?

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

Re: RFC: Update ISL under gcc/infrastructure/ ? // Remove CLooG?

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. *

Re: [GSoC] Elimination of CLooG library installation dependency

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

Re: [GSoC] Elimination of CLooG library installation dependency

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

Re: [GSoC] the separate option for all dimensions

On August 12, 2014 8:15:34 AM CEST, Roman Gareev gareevro...@gmail.com 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

Re: [GSoC] Elimination of CLooG library installation dependency

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

Re: [GSoC] Elimination of CLooG library installation dependency

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

Re: [GSoC] Elimination of CLooG library installation dependency

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

Re: [GSoC] Elimination of CLooG library installation dependency

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

Re: [GSoC] the separate option for all dimensions

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)

Re: [GSoC] Elimination of CLooG library installation dependency

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.

Re: [GSoC] the separate option for all dimensions

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

Re: [GSoC] checking for the loop parallelism

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

Re: Replacement of isl_int by isl_val

LGTM. Cheers, Tobias

Re: [GSoC] checking for the loop parallelism

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

Re: [GSoC] checking for the loop parallelism

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

Re: [GSoC] checking for the loop parallelism

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

Re: [GSoC] type of an isl_ast_expr_id

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

Re: [GSoC] type of an isl_ast_expr_id

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

Re: [GSoC] type of an isl_ast_expr_id

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

Re: [GSoC] type of an isl_ast_expr_id

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

Re: [GSoC] generation of Gimple code from isl_ast_node_if

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

Re: [GSoC] generation of Gimple code from isl_ast_node_if

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

Re: [GSoC] generation of Gimple code from isl_ast_node_if

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

Re: [GSoC] generation of Gimple code from isl_ast_node_if

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) {

Re: [GSoC] generation of Gimple code from isl_ast_node_if

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

Re: [GSoC] generation of Gimple code from isl_ast_node_if

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);

Re: [GSoC] generation of Gimple code from isl_ast_node_if

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

Re: [GSoC] generation of Gimple code from isl_ast_node_if

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

Re: [GSoC] generation of Gimple code from isl_ast_node_if

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:

Re: [GSoC] Handling of isl_ast_op_pdiv_q and isl_ast_op_pdiv_r

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

Re: [GSoC] A bug related to induction variables and blocks

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

Re: [GSoC] generation of Gimple code from isl_ast_node_if

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)

Re: [GSoC] generation of Gimple code from isl_ast_node_block

On 23/07/2014 11:13, Rainer Orth wrote: Roman Gareev gareevro...@gmail.com 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 gareevro...@gmail.com gcc/ *

Re: [GSoC] Handling of isl_ast_op_pdiv_q and isl_ast_op_pdiv_r

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

Re: [GSoC] A bug related to induction variables and blocks

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);

Re: [GSoC] extend schedules

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

Re: [GSoC] generation of Gimple code from 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

Re: [GSoC] generation of Gimple code from isl_ast_node_user

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

Re: [GSoC] generation of Gimple code from isl_ast_node_user

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

Re: [GSoC] A formatting issue.

On July 20, 2014 1:39:08 PM CEST, Roman Gareev gareevro...@gmail.com 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

Re: [GSoC] Addition of ISL AST generation to Graphite

On July 20, 2014 1:29:30 PM CEST, Roman Gareev gareevro...@gmail.com 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

Re: [GSoC] generation of Gimple code from isl_ast_node_user

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

Re: [GSoC] generation of Gimple loops with empty bodies

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?

Re: [GSoC] Addition of ISL AST generation to Graphite

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

Re: [GSoC] generation of Gimple code from isl_ast_node_user

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 (vecT, A, vl_embed *v,

Re: [GSoC] Addition of ISL AST generation to Graphite

On 16/07/2014 11:36, Richard Biener wrote: On Tue, Jul 15, 2014 at 5:34 PM, Tobias Grosser tob...@grosser.es 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

Re: [GSoC] Addition of ISL AST generation to Graphite

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

Re: [GSoC] Addition of ISL AST generation to Graphite

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

Re: [GSoC] generation of Gimple code from isl_ast_node_user

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

Re: [GSoC] generation of Gimple code from isl_ast_node_user

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)) {

Re: [GSoC] generation of Gimple loops with empty bodies

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

Re: [GSoC] generation of Gimple loops with empty bodies

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::mapisl_id *, tree

Re: [GSoC] generation of Gimple loops with empty bodies

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

Re: [GSoC] generation of Gimple loops with empty bodies

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

  1   2   >