Fix PR64878: do not jump thread across two loop iterations

bootstrap and regression testing on x86_64-linux. Ok to commit? Thanks, Sebastian From 59c486720749fc3d5feac2a5364d52eac60ba2d0 Mon Sep 17 00:00:00 2001 From: Sebastian Pop s@samsung.com Date: Wed, 4 Feb 2015 11:17:54 -0600 Subject: [PATCH] PR 64878: do not jump thread across more than one back-edge

Re: [patch] fix PR65048: check that jump-thread paths are still valid

Jeff Law wrote: These kinds of situations are normally pruned out in mark_threaded_blocks. I added the FSM code generation before calling mark_threaded_blocks. The dumps for the FSM threads are a bit sparse -- they don't show the entire path. That makes it much harder to see what's going

[patch] fix PR65048: check that jump-thread paths are still valid

, Sebastian From 79b93a743649b898010cfea70769184bca28efb1 Mon Sep 17 00:00:00 2001 From: Sebastian Pop seb...@gmail.com Date: Tue, 10 Feb 2015 22:36:50 +0100 Subject: [PATCH] check that paths are still valid to be threaded PR tree-optimization/65048 * tree-ssa-threadupdate.c (valid_jump_thread_path

Re: Fix PR64878: do not jump thread across two loop iterations

Jakub Jelinek wrote: On Thu, Feb 05, 2015 at 08:21:46AM +0100, Richard Biener wrote: On February 4, 2015 10:20:06 PM CET, Sebastian Pop seb...@gmail.com wrote: The attached patch stops the recursion in the detection of FSM jump-threads at loop phi nodes after having visited a loop phi

Fix PR 65177: diamonds are not valid execution threads for jump threading

-linux, and fixes the make check of hmmer. Ok to commit? Thanks, Sebastian From 8c82e8b8c7d864c009bb7a116faf4acf64954704 Mon Sep 17 00:00:00 2001 From: Sebastian Pop seb...@gmail.com Date: Tue, 17 Mar 2015 20:28:19 +0100 Subject: [PATCH] fix 65177 PR tree-optimization/65177 * cfghooks.c

Re: Fix PR 65177: diamonds are not valid execution threads for jump threading

? From 8f1516235bce3e1c4f359149dcc546d813ed7817 Mon Sep 17 00:00:00 2001 From: Sebastian Pop seb...@gmail.com Date: Tue, 17 Mar 2015 20:28:19 +0100 Subject: [PATCH] diamonds are not valid execution threads for jump threading PR tree-optimization/65177 * tree-ssa-threadupdate.c (verify_seme): Renamed

Re: Fix PR 65177: diamonds are not valid execution threads for jump threading

Richard Biener wrote: On Thu, Mar 19, 2015 at 8:54 PM, Sebastian Pop seb...@gmail.com wrote: Richard Biener wrote: please instead fixup after copy_bbs in duplicate_seme_region. Thanks for the review. Attached patch that does not modify copy_bbs. Fixes make check in hmmer and make

Re: [PATCH/AARCH64] Add missing definition of crypto instruction on cortex-a57.md

James Greenhalgh wrote: On Wed, Mar 11, 2015 at 04:24:07PM +, Ramana Radhakrishnan wrote: Attached patch as text. 2015-03-11 Junmo Park junmoz.p...@samsung.com * config/arm/cortex-a57.md (cortex_a57_crypto_simple): Add crypto_sha256_fast.

Re: Fix PR 65177: diamonds are not valid execution threads for jump threading

Jeff Law wrote: PR tree-optimization/65177 * tree-ssa-threadupdate.c (verify_seme): Renamed verify_jump_thread. (bb_in_bbs): New. (duplicate_seme_region): Renamed duplicate_thread_path. Redirect all edges not adjacent on the path to the original code. OK for the

Re: [patch] fix PR65048: check that jump-thread paths are still valid

Jeff Law wrote: Registering FSM jump thread: (10, 12) (12, 13) (13, 15) (15, 3) [ snip ] Registering FSM jump thread: (7, 10) (10, 12) (12, 13) (13, 14) What I'm having a bit of trouble wrapping my head around is how can those two paths both be valid when you register them?

Re: [patch] fix PR65048: check that jump-thread paths are still valid

Jeff Law wrote: On 02/18/15 15:27, Sebastian Pop wrote: The dumps for the FSM threads are a bit sparse -- they don't show the entire path. That makes it much harder to see what's going on. Would a patch improving the FSM dumps ok to commit separately to trunk? Most definitely. I realize

Re: [patch] fix PR65048: check that jump-thread paths are still valid

On Thu, Feb 26, 2015 at 7:56 AM, Jeff Law l...@redhat.com wrote: On 02/13/15 16:50, Sebastian Pop wrote: Hi, the attached patch fixes PR65048 by checking before jump-threading that a path to be threaded is still valid: as the testcase shows, there may be paths that are not connected

Re: [patch] fix PR65048: check that jump-thread paths are still valid

Jeff Law wrote: On 02/25/15 12:18, Sebastian Pop wrote: Jeff Law wrote: On 02/18/15 15:27, Sebastian Pop wrote: The dumps for the FSM threads are a bit sparse -- they don't show the entire path. That makes it much harder to see what's going on. Would a patch improving the FSM dumps ok

Re: [PATCH] [ARM] Add support for the Samsung Exynos M1 processor

Hi, from what I understand, Evandro has addressed the comments from Kyrill. Are there other problems to be addressed before the patches can go in? Thanks, Sebastian On Tue, Mar 31, 2015 at 7:30 PM, Evandro Menezes e.mene...@samsung.com wrote: Hi, Kyrill. At this moment, it suffices to use

Re: [PATCH] [ARM] Add support for the Samsung Exynos M1 processor

Hi, On Thu, Apr 2, 2015 at 5:51 PM, James Greenhalgh james.greenha...@arm.com wrote: Trunk is currently in Stage 4 development, these patches are fairly low-risk, but they are certainly not regression fixes. I'll defer to port maintainers and release managers for the final say, but in my

Re: [PATCH] [ARM] Add support for the Samsung Exynos M1 processor

On Sat, Apr 4, 2015 at 1:25 AM, Richard Biener rguent...@suse.de wrote: On April 4, 2015 5:03:14 AM GMT+02:00, Sebastian Pop seb...@gmail.com wrote: On Fri, Apr 3, 2015 at 4:09 PM, James Greenhalgh james.greenha...@arm.com wrote: On Fri, Apr 03, 2015 at 07:53:12PM +0100, Ramana Radhakrishnan

Re: [PATCH] [ARM] Add support for the Samsung Exynos M1 processor

On Fri, Apr 3, 2015 at 4:09 PM, James Greenhalgh james.greenha...@arm.com wrote: On Fri, Apr 03, 2015 at 07:53:12PM +0100, Ramana Radhakrishnan wrote: On Fri, Apr 3, 2015 at 5:17 PM, Sebastian Pop seb...@gmail.com wrote: Hi, On Thu, Apr 2, 2015 at 5:51 PM, James Greenhalgh james.greenha

Re: [PATCH] Do not constrain on REAL_TYPE

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 for integer_cst constants (I in ISL stands for

Re: fix PR46029: reimplement if conversion of loads and stores

On Thu, Jun 25, 2015 at 4:43 AM, Richard Biener richard.guent...@gmail.com wrote: when the new scheme triggers vectorization cannot succeed on the result as we get if (cond) *p = val; if-converted to tem = cond ? p : scratch; *tem = val; That's correct. and if (cond)

Re: [PATCH] Do not constrain on REAL_TYPE

On Wed, Jun 24, 2015 at 5:24 PM, Aditya Kumar hiradi...@msn.com wrote: From: Aditya Kumar aditya...@samsung.com gcc/ChangeLog: 2015-06-24 Aditya Kumar aditya...@samsung.com Sebastian Pop s@samsung.com * graphite-sese-to-poly.c (parameter_index_in_region): Discard

Re: [PATCH] Restore previous change for gimple_phi_iterator

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 was: - gimple_stmt_iterator psi = gsi_for_stmt (use_stmt); +

Re: [PATCH] Restore previous change for gimple_phi_iterator

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 limit_scops(). Maybe the commit message could

Re: [PATCH] Restore previous change for gimple_phi_iterator

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-sese-to-poly.c (rewrite_cross_bb_scalar_deps

Re: [PATCH] Graphite cannot handle return stmt

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 out in case of a return statement. Looks

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

relevant changes in incremental steps to fix those bugs, and finally we intend to remove limit_scops. 2015-06-29 Aditya Kumar aditya...@samsung.com Sebastian Pop s@samsung.com * graphite-scop-detection.c (build_scops_1): Discard scops for which entry==exit Looks

Re: [PATCH] [graphite] Reduce the number of params in a scop to 3

Sebastian Pop wrote: Aditya Kumar wrote: More than 3 params consumes too much memory while bootstrapping gcc with graphite enabled. Ok. I will commit the patch. Thanks for fixing bootstrap with graphite enabled. We will increase the max when we will use ISL's mechanism to count

Re: [PATCH] [graphite] Reduce the number of params in a scop to 3

Aditya Kumar wrote: More than 3 params consumes too much memory while bootstrapping gcc with graphite enabled. Ok. I will commit the patch. Thanks for fixing bootstrap with graphite enabled. Sebastian

Re: [RFC, PR66873] Use graphite for parloops

On Sun, Jul 26, 2015 at 4:21 PM, Tom de Vries tom_devr...@mentor.com wrote: I wrote an equivalent test-case in C: ... $ cat src/gcc/testsuite/gcc.dg/autopar/outer-7.c /* { dg-do compile } */ /* { dg-options -O2 -ftree-parallelize-loops=2 -fdump-tree-parloops-details -fdump-tree-optimized }

Re: [RFC, PR66873] Use graphite for parloops

Tom de Vries wrote: Fix reduction safety checks * graphite-sese-to-poly.c (is_reduction_operation_p): Limit flag_associative_math to SCALAR_FLOAT_TYPE_P. Honour TYPE_OVERFLOW_TRAPS and TYPE_OVERFLOW_WRAPS for INTEGRAL_TYPE_P. Only allow wrapping fixed-point

Re: [PATCH] gcc: fix building w/isl-0.15

://isl.gforge.inria.fr/isl-0.15.tar.bz2? Also, once that is done, I will commit the following patch updating the documentation. Thanks, Sebastian From 189565d5f0cdcb54aac309316316456b88957ef6 Mon Sep 17 00:00:00 2001 From: Sebastian Pop seb...@gmail.com Date: Tue, 21 Jul 2015 20:26:36 + Subject: [PATCH

Re: [PATCH] Don't allow unsafe reductions in graphite

Richard Biener wrote: On Wed, Jul 22, 2015 at 6:00 PM, Tom de Vries tom_devr...@mentor.com wrote: Currently bootstrapping and reg-testing on x86_64. OK for trunk? OK 5 and 4.9 release branches? Ok if Sebastian is fine with it. Ok to backport as well. Thanks Tom for the patches.

Re: [PATCH] gcc: fix building w/isl-0.15

Jeff Law wrote: On 07/21/2015 02:32 PM, Sebastian Pop wrote: Could somebody with access to sourceware.org upload a tar.bz2 of the required version of isl from http://isl.gforge.inria.fr/isl-0.15.tar.bz2? Also, once that is done, I will commit the following patch updating the documentation

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

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/graphite-scop-detection.c | 72

[PATCH] enable loop fusion with ISL scheduler

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 (optimize_isl): Use ISL_SCHEDULE_FUSE_MAX when

[PATCH] [graphite] fix pr61929

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? Thanks. 2015-07-15 Aditya Kumar aditya...@samsung.com Sebastian Pop s

Re: [RFC, PR66873] Use graphite for parloops

Tom de Vries wrote: So I wondered, why not always use the graphite dependency analysis in parloops. (Of course you could use -floop-parallelize-all, but that also changes the heuristic). So I wrote a patch for parloops to use graphite dependency analysis by default (so without

Re: [RFC, PR66873] Use graphite for parloops

Tom de Vries wrote: graphite dependence analysis is too slow to be enabled unconditionally. (read: hours in some simple cases - see bugzilla) Haha, cool! ;-) Maybe it is still reasonable to use graphite to analyze the code inside OpenACC kernels regions -- maybe such code can reasonably

[PATCH] remove tree-browser

Regstrapped on amd64-linux. Ok for trunk? Thanks, Sebastian 2015-07-20 Sebastian Pop s@samsung.com * Makefile.in: Remove use of TREEBROWSER. * config.in: Regenerated. * configure: Regenerated. * configure.ac: Remove definition

[PATCH] [graphite] avoid generation of empty guards in trivial cases

We used to insert a trivial integer_onep condition around loops we know have more than an iteration. This patch avoids generating those conditions. * graphite-isl-ast-to-gimple.c (graphite_create_new_loop_guard): Do not call create_empty_if_region_on_edge when cond_expr is true.

[PATCH 1/2] [graphite] add an upper limit on the number of array references

* graphite-scop-detection.c (build_scops): Do not handle scops with more than PARAM_GRAPHITE_MAX_ARRAYS_PER_SCOP arrays. * params.def (PARAM_GRAPHITE_MAX_ARRAYS_PER_SCOP): New. --- gcc/graphite-scop-detection.c | 11 +++ gcc/params.def| 7 +++

[PATCH 2/2] [graphite] a scalar depending on vdefs in the current region is not invariant

When a scalar is defined in function of an array reference in the current scop, it does variate. Graphite cannot represent the condition in scop-11.c, as a[*] variates in the current region, and it is not an affine condition: for (j = 0; j <= 20; j++) a[j] = b + i; if (a[12] == 23)

Re: [PATCH] Preserve the original program while using graphite

On Fri, Nov 13, 2015 at 3:08 PM, Tom de Vries wrote: > On 11/11/15 23:54, Aditya Kumar wrote: >> >> Earlier, graphite used to translate portions of the original program after >> scop-detection in order to represent the SCoP into polyhedral model. This >> was >> required

Re: [PATCH 05/N] Fix memory leaks in graphite

On Fri, Nov 13, 2015 at 6:15 AM, Richard Biener wrote: > On Fri, Nov 13, 2015 at 12:43 PM, Martin Liška wrote: >> Hello. >> >> Patch survives regbootstrap on x86_64-linux-gnu. >> Ready for trunk? Thanks Martin for the patch. Sebastian > > Ok. > >

[PATCH 2/2] [graphite] improve construction of the original schedule

The patch builds the original schedule based on the now optimized scattering dimension instead of building one based on the loop index only. The implementation is simpler and catches more cases where the original schedule and the transformed schedule are the same, such as the one below: for (i =

[PATCH 1/2] [graphite] add testsuite automatic dg-options and dg-do action for isl-ast-gen-* and fuse-* files

--- gcc/testsuite/gcc.dg/graphite/fuse-1.c | 10 +++--- gcc/testsuite/gcc.dg/graphite/fuse-2.c | 4 +--- gcc/testsuite/gcc.dg/graphite/graphite.exp | 2 ++ gcc/testsuite/gcc.dg/graphite/isl-ast-gen-blocks-1.c| 3 ---

[PATCH] remove parameter_rename_map

This map was used in the transition to the new scop detection: with the new scop detection, we do not need this map anymore. * graphite-isl-ast-to-gimple.c (gcc_expression_from_isl_ast_expr_id): Remove use of parameter_rename_map. (copy_def): Remove.

[PATCH 1/2] [graphite] do not create unnecessary dimensions in scop scattering

* graphite-sese-to-poly.c (build_pbb_scattering_polyhedrons): Remove. (build_pbb_minimal_scattering_polyhedrons): New. (build_scop_scattering): Remove. (build_scop_minimal_scattering): New. (build_scop_scattering): Call

[PATCH 2/2] add original schedule to scop

From: Abderrazek Zaafrani * graphite-optimize-isl.c (optimize_isl): Call isl_union_map_is_equal. * graphite-poly.c (new_scop): Initialize original_schedule. (free_scop): Free original_schedule. * graphite-poly.h (struct scop): Add field original_schedule.

[PATCH] [graphite] improve debug of codegen

From: Aditya Kumar - fix printing of ISL stmt and parameter names - move dot_scop* functions outside of anonymous namespace. * graphite-isl-ast-to-gimple.c: Include tree-cfg.h. (translate_isl_ast_node_user): Add more dumps: call print_loops_bb. *

[PATCH] enable loop fusion on isl-15

* graphite-optimize-isl.c (optimize_isl): Call isl_options_set_schedule_maximize_band_depth. * gcc.dg/graphite/fuse-1.c: New. * gcc.dg/graphite/fuse-2.c: New. * gcc.dg/graphite/interchange-13.c: Remove bogus check. --- gcc/graphite-optimize-isl.c

[PATCH] [graphite] do not collect cold loops in scops

* graphite-scop-detection.c (loop_is_valid_scop): Call optimize_loop_nest_for_speed_p. --- gcc/graphite-scop-detection.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/gcc/graphite-scop-detection.c b/gcc/graphite-scop-detection.c index ae8497d..f22e9cc 100644 ---

Re: improved RTL-level if conversion using scratchpads [half-hammock edition]

On Fri, Nov 6, 2015 at 6:32 AM, Bernd Schmidt <bschm...@redhat.com> wrote: > On 11/06/2015 03:10 PM, Sebastian Pop wrote: >> >> On Fri, Nov 6, 2015 at 2:56 AM, Bernd Schmidt <bschm...@redhat.com> wrote: >>> >>> Formatting problem, here a

Re: [PATCH] Do not allow irreducible loops/regions in a scop

On Thu, Nov 5, 2015 at 10:12 PM, Aditya Kumar wrote: > Irreducible regions are not going to be optimized by ISL > so discard them early. > > gcc/ChangeLog: > > 2015-11-06 Aditya Kumar > > * graphite-scop-detection.c

Re: improved RTL-level if conversion using scratchpads [half-hammock edition]

On Fri, Nov 6, 2015 at 2:56 AM, Bernd Schmidt wrote: > Formatting problem, here and in a few other places. I didn't fully read the > patch this time around. > > I'm probably not reviewing further patches because I don't see this > progressing to a state where it's acceptable.

Re: using scratchpads to enhance RTL-level if-conversion: revised patch

Hi Abe, could you please avoid double negations, and please use early returns rather than huge right indentations: + if (! not_a_scratchpad_candidate) + { +if (MEM_SIZE_KNOWN_P (orig_x)) +{ + const size_t size_of_MEM = MEM_SIZE (orig_x); + + if (size_of_MEM <=

Re: using scratchpads to enhance RTL-level if-conversion: revised patch

the + THEN block and the set of 'a', if any. */ This comment duplicates the same content as the comment before the loop. Please remove. On Thu, Oct 8, 2015 at 8:08 AM, Sebastian Pop <seb...@gmail.com> wrote: > Hi Abe, > > could you please avoid double negations, and &

Re: [PATCH] gather bbs and conditions in a single walk through dominators

will use that vector in a patch that removes the out-of-ssa translation of scalar dependences: we will iterate through the basic blocks of a region to record scalar dependences crossing bbs or going out of the region. The patch passes bootstrap and regtest on x86_64-linux. Sebastian Pop wrote: > 2

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

2015-10-05 Aditya Kumar <aditya...@samsung.com> Sebastian Pop <s@samsung.com> * graphite-dependences.c (scop_get_transformed_schedule): Remove. (no_violations): Remove. (subtract_commutative_associative_d

Re: [PATCH 2/3] remove unused struct base_alias_pair

On Wed, Oct 7, 2015 at 3:11 AM, Richard Biener <richard.guent...@gmail.com> wrote: > On Tue, Oct 6, 2015 at 10:45 PM, Sebastian Pop <s@samsung.com> wrote: >> 2015-10-06 Aditya Kumar <aditya...@samsung.com> >> Sebastian Pop <s@samsung.c

[PATCH] gather bbs and conditions in a single walk through dominators

2015-10-06 Aditya Kumar <aditya...@samsung.com> Sebastian Pop <s@samsung.com> * graphite-dependences.c (scop_get_dependences): Do not use SCOP_BBS. * graphite-isl-ast-to-gimple.c (get_max_schedule_dimens

[PATCH] remove unused code

--- gcc/graphite-scop-detection.c | 3 --- gcc/sese.c| 1 - gcc/sese.h| 8 +--- 3 files changed, 1 insertion(+), 11 deletions(-) diff --git a/gcc/graphite-scop-detection.c b/gcc/graphite-scop-detection.c index 7e5039c..43e03a6 100644 ---

[PATCH] remove unused code

2015-10-07 Aditya Kumar <aditya...@samsung.com> Sebastian Pop <s@samsung.com> * graphite-scop-detection.c (parameter_index_in_region): Remove use of SESE_ADD_PARAMS. (find_scop_parameters): Same.

[PATCH 2/3] remove unused struct base_alias_pair

2015-10-06 Aditya Kumar <aditya...@samsung.com> Sebastian Pop <s@samsung.com> * graphite-poly.c (free_data_refs_aux): Remove. (free_gimple_poly_bb): Do not call free_data_refs_aux. * graphite-poly.h (struct bas

[PATCH 3/3] move dr->alias_set to a helper structure

2015-10-06 Aditya Kumar <aditya...@samsung.com> Sebastian Pop <s@samsung.com> * graphite-poly.c (new_scop): Initialize drs. * graphite-poly.h (struct dr_info): New. (struct scop): Add drs. * g

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

2015-10-06 Aditya Kumar <aditya...@samsung.com> Sebastian Pop <s@samsung.com> * graphite-poly.c (new_poly_dr): Remove dr_base_object_set. Do not set PDR_BASE_OBJECT_SET. * graphite-poly.h (po

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

--- gcc/graphite-dependences.c | 36 gcc/graphite-poly.h| 3 --- 2 files changed, 39 deletions(-) diff --git a/gcc/graphite-dependences.c b/gcc/graphite-dependences.c index e39394a..37535d5 100644 --- a/gcc/graphite-dependences.c +++

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

--- gcc/graphite-dependences.c | 255 + gcc/graphite-poly.h| 3 - 2 files changed, 1 insertion(+), 257 deletions(-) diff --git a/gcc/graphite-dependences.c b/gcc/graphite-dependences.c index e39394a..2c4f92c 100644 ---

[PATCH] move graphite bookkeeping from sese to sese_info

2015-10-06 Aditya Kumar <aditya...@samsung.com> Sebastian Pop <s@samsung.com> * graphite-isl-ast-to-gimple.c (translate_isl_ast_to_gimple): Use an sese_info_p. (copy_def): Same. (copy_interna

[PATCH 1/2] clean up debug functions

2015-10-07 Aditya Kumar <aditya...@samsung.com> Sebastian Pop <s@samsung.com> * graphite-poly.c (print_iteration_domain): Remove verbosity. Remove OpenScop formatting. (print_iteration_domains): Same. (debug_iteration_d

[PATCH 2/2] add dump of data dependences

2015-10-07 Aditya Kumar <aditya...@samsung.com> Sebastian Pop <s@samsung.com> * graphite-dependences.c (scop_get_dependences): Add dump of the data dependence graph. * graphite-poly.c (print_isl_uni

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

Tobias Grosser wrote: From the graphite side, this is right. One thing I am not sure about if we need to keep these flags as 'do-nothing' flags to meet certain backward compatibility guarantees in gcc. The patch keeps all the flags and makes them alias of a single flag -floop-nest-optimize.

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

that code as it is replaced by ISL's scheduler. The patches pass make check and bootstrap (in progress) with -fgraphite-identity. Ok to commit? Thanks, Sebastian Sebastian Pop (2): remove -floop-unroll-and-jam remove -floop-* flags gcc/Makefile.in|2 - gcc

[PATCH 2/2] remove -floop-* flags

representation. - - Copyright (C) 2009-2015 Free Software Foundation, Inc. - Contributed by Sebastian Pop sebastian@amd.com and - Pranav Garg pranav.garg2...@gmail.com. - -This file is part of GCC. - -GCC is free software; you can redistribute it and/or modify -it under the terms of the GNU

[PATCH 1/2] remove -floop-unroll-and-jam

--- gcc/common.opt | 4 +- gcc/doc/invoke.texi | 8 +- gcc/graphite-isl-ast-to-gimple.c | 102 +- gcc/graphite-optimize-isl.c | 179 --- gcc/graphite-poly.c | 3 +- gcc/graphite-poly.h

Re: [patch] fix bootstrap if no ISL is available.

On Thu, Aug 27, 2015 at 3:19 PM, Andreas Tobler andreast-l...@fgznet.ch wrote: Hi all, I think this is obvious? Yes. Sorry for missing testing without ISL. I have committed a similar patch just after I got pinged that my patch broke builds without ISL. Sebastian Thanks, Andreas

[PATCH 0/3] [linaro/gcc-4_9-branch] backport fixes to jump-threading

Hi, As I was backporting the jump-thread patches to the AOSP gcc 4.9, I found that the linaro branch does not have the following three fixes. Ok to commit to the linaro/gcc-4_9-branch? Thanks, Sebastian Sebastian Pop (3): backport patch to fix PR65048 backport patch to fix PR65177

[PATCH 1/3] backport patch to fix PR65048

PR tree-optimization/65048 * tree-ssa-threadupdate.c (valid_jump_thread_path): New. (thread_through_all_blocks): Call valid_jump_thread_path. Remove invalid FSM jump-thread paths. PR tree-optimization/65048 * gcc.dg/tree-ssa/ssa-dom-thread-9.c: New. ---

[PATCH 0/3] [linaro/gcc-4_9-branch] backport fixes to jump-threading

Hi, As I was backporting the jump-thread patches to the AOSP gcc 4.9, I found that the linaro branch does not have the following three fixes. Ok to commit to the linaro/gcc-4_9-branch? Thanks, Sebastian Sebastian Pop (3): backport patch to fix PR65048 backport patch to fix PR65177

[PATCH 3/3] backport fix for PR65735

PR tree-optimization/65735 * tree-ssa-threadedge.c (fsm_find_control_statement_thread_paths): Remove visited_phis argument, add visited_bbs, avoid recursing into the same bb rather than just into the same phi node. (thread_through_normal_block): Adjust

[PATCH 2/3] backport patch to fix PR65177

PR tree-optimization/65177 * tree-ssa-threadupdate.c (verify_seme): Renamed verify_jump_thread. (bb_in_bbs): New. (duplicate_seme_region): Renamed duplicate_thread_path. Redirect all edges not adjacent on the path to the original code. *

Re: [PATCH] fix PR53852: stop ISL after a given number of operations

Richard Biener wrote: > > * gcc.dg/graphite/uns-interchange-12.c: Adjust pattern to pass > > with > > both isl-0.12 and isl-0.15. > > Does it mean with 0.15 we now "time out" on some of the cases? "time out" will not trigger on the testcases modified in this patch. >

Re: [PATCH] 2015-07-31 Benedikt Huber <benedikt.hu...@theobroma-systems.com> Philipp Tomsich <philipp.toms...@theobroma-systems.com>

On Wed, Aug 26, 2015 at 11:58 AM, Benedikt Huber wrote: > ping > > [PATCH v4][aarch64] Implemented reciprocal square root (rsqrt) estimation in > -ffast-math > > https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02698.html > >> On 31 Jul 2015, at 19:05, Benedikt

Re: [PATCH] select isl-0.15 in download_prerequisites

On Fri, Sep 4, 2015 at 12:42 AM, VandeVondele Joost wrote: > For the recent fix of PR53852, isl-0.15 is needed, I just went to the documentation of isl-0.14 and I see that it also provides the functionality to count the number of isl operations:

[PATCH] fix PR53852: stop ISL after a given number of operations

2015-09-02 Sebastian Pop <s@samsung.com> * config.in: Regenerate. * configure: Regenerate. * configure.ac (HAVE_ISL_CTX_MAX_OPERATIONS): Detect. * graphite-optimize-isl.c (optimize_isl): Stop computatio

Re: [PATCH] fix PR53852: stop ISL after a given number of operations

On Tue, Sep 15, 2015 at 8:54 AM, Richard Biener <richard.guent...@gmail.com> wrote: > On Thu, Sep 3, 2015 at 5:22 PM, Sebastian Pop <seb...@gmail.com> wrote: >> Richard Biener wrote: >>> > * gcc.dg/graphite/uns-interchange-12.c: Adjust pattern to >&

[PATCH] remove dead code of commutative_reductions

to the data dependence graph.) Patch passed bootstrap and check on x86_64-linux with ISL-0.15. I will commit this patch to trunk. 2015-09-29 Sebastian Pop <s@samsung.com> Aditya Kumar <aditya...@samsung.com> * graphite-sese-to-poly.c (gsi_for_phi_n

[PATCH] use MIN fusion for ISL-14

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) S_4(c1, c3); S_5(c1); } for (int

Re: [PATCH] remove dead code of commutative_reductions

Tobias Grosser wrote: > 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 th

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

-linux when compiled with -m32. Patch passed bootstrap with BOOT_CFLAGS="-g -O2 -fgraphite-identity -floop-nest-optimize" and check on x86_64-linux using ISL-0.15. 2015-09-28 Sebastian Pop <s@samsung.com> Aditya Kumar <aditya...@samsung.com> PR t

[PATCH 1/2] add recursion on the inner loops

We now check that all data references in the current loop and inner loops contained within loop are valid in an outer region before declaring that the outer loop is a valid scop. 2015-09-30 Sebastian Pop <s@samsung.com> Aditya Kumar <aditya...@samsung.com>

[PATCH] correctly handle non affine data references

PR tree-optimization/66980 * graphite-scop-detection.c (stmt_has_simple_data_refs_p): Return false when data reference analysis has failed. --- gcc/graphite-scop-detection.c| 7 +++ gcc/testsuite/gcc.dg/graphite/scop-pr66980.c | 10 ++ 2 files

[PATCH 1/3] move scop detection related stuff to graphite-scop-detection.c

From: hiraditya --- gcc/graphite-scop-detection.c | 1943 + gcc/graphite-sese-to-poly.c | 184 +--- 2 files changed, 1207 insertions(+), 920 deletions(-) diff --git a/gcc/graphite-scop-detection.c b/gcc/graphite-scop-detection.c

[PATCH 2/3] move param detection to scop detection

--- gcc/graphite-poly.c | 68 ++- gcc/graphite-poly.h | 11 +- gcc/graphite-scop-detection.c| 217 ++--- gcc/graphite-sese-to-poly.c | 324 --- gcc/graphite-sese-to-poly.h

[PATCH 3/3] increase the number of parameters

--- 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 100644 --- a/gcc/params.def +++ b/gcc/params.def @@ -835,7 +835,7 @@

Re: using scratchpads to enhance RTL-level if-conversion: the new patch now passes bootstrap with the default BUILD_CONFIG [i.e. no stage2-to-stage3 comparison errors even with debugging info off in s

On Mon, Oct 5, 2015 at 6:02 PM, Joseph Myers wrote: > Is this Samsung Austin R Center? If so, yes, there's an assignment Yes.

[PATCH] fix PR67700

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 <aditya...@samsung.com> Sebastian Pop <s@sa

[PATCH 1/2] [graphite] rename flag_loop_optimize_isl to flag_loop_nest_optimize

--- gcc/common.opt | 2 +- gcc/graphite-poly.c | 2 +- gcc/graphite.c | 2 +- gcc/toplev.c| 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/gcc/common.opt b/gcc/common.opt index e1617c4..e593631 100644 --- a/gcc/common.opt +++ b/gcc/common.opt @@ -1379,7

[PATCH 2/2] [graphite] fix invalid bounds on array refs

While enabling graphite in -O3 we found a Fortran testcase that fails because the max of the type domain is -1. We used to add that as a constraint to the elements accessed by the array, leading to a unfeasible constraint: 0 <= i <= -1. Having that constraint, drops the data reference as that

[PATCH] [graphite] fix PR68550: do not handle ISL loop peeled statements

In case ISL did some loop peeling, like this: S_8(0); for (int c1 = 1; c1 <= 5; c1 += 1) { S_8(c1); } S_8(6); we should not copy loop-phi nodes in S_8(0) or in S_8(6). * graphite-isl-ast-to-gimple.c (copy_loop_phi_nodes): Add dump. (copy_bb_and_scalar_dependences):

[PATCH] [graphite] handle missing isl_ast_expr

>From ISL's documentation, isl_ast_op_zdiv_r is equal to zero iff the remainder on integer division is zero. Code generate a modulo operation for that. * graphite-isl-ast-to-gimple.c (binary_op_to_tree): Handle isl_ast_op_zdiv_r. (gcc_expression_from_isl_expr_op): Same.

  1   2   3   4   5   >