This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][0/n] Merge from match-and-simplify
- From: Richard Biener <rguenther at suse dot de>
- To: ramrad01 at arm dot com
- Cc: Kyrill Tkachov <kyrylo dot tkachov at arm dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 17 Oct 2014 13:51:17 +0200 (CEST)
- Subject: Re: [PATCH][0/n] Merge from match-and-simplify
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1410151450430 dot 20733 at zhemvz dot fhfr dot qr> <543EA0CE dot 5040705 at arm dot com> <CAJA7tRYVj66Mq6-vwOLh8U+VLoqXsJ3kJKssXBoutxmbggning at mail dot gmail dot com> <alpine dot LSU dot 2 dot 11 dot 1410171009390 dot 9891 at zhemvz dot fhfr dot qr>
On Fri, 17 Oct 2014, Richard Biener wrote:
> On Fri, 17 Oct 2014, Ramana Radhakrishnan wrote:
>
> > On Wed, Oct 15, 2014 at 5:29 PM, Kyrill Tkachov <kyrylo.tkachov@arm.com> wrote:
> > >
> > > On 15/10/14 14:00, Richard Biener wrote:
> > >>
> > >>
> > >> Any comments and reviews welcome (I don't think that
> > >> my maintainership covers enough to simply check this in
> > >> without approval).
> > >>
> > > Hi Richard,
> > >
> > > The match-and-simplify branch bootstrapped successfully on
> > > aarch64-none-linux-gnu FWIW.
> > >
> >
> > What about regression tests ?
>
> Note the branch isn't regression free on x86_64 either. The branch
> does more than I want to merge to trunk (and it also retains all
> folding code I added patterns for). I've gone farther there to
> explore whether it will end up working in the end and what kind
> of features the IL and the APIs need.
>
> I've pasted testsuite results on x86_64 below for rev. 216324
> which is based on trunk rev. 216315 which unfortunately has
> lots of regressions on its own.
>
> This is why I want to restrict the effect of the machinery to
> fold (), fold_stmt () and tree-ssa-forwprop.c for the moment
> and merge individual patterns (well, maybe in small groups)
> separately to allow for easy bi-section.
>
> I suppose I should push the most visible change to trunk first,
> namely tree-ssa-forwprop.c folding all statements via fold_stmt
> after the merge. I suspect this alone can have some odd effects
> like the sub + cmp fusing. That would be sth like the patch
> attached below.
Just finished testing this (with -m32 on x86_64), showing regressions
in the testsuite like
FAIL: gcc.dg/tree-ssa/slsr-19.c scan-tree-dump-times optimized " \\\\* y"
1
FAIL: gcc.dg/vect/bb-slp-27.c -flto -ffat-lto-objects
scan-tree-dump-times slp2
"basic block vectorized" 1
FAIL: gcc.dg/vect/bb-slp-27.c scan-tree-dump-times slp2 "basic block
vectorized"
1
FAIL: gcc.dg/vect/bb-slp-8b.c -flto -ffat-lto-objects
scan-tree-dump-times slp2
"basic block vectorized" 1
FAIL: gcc.dg/vect/bb-slp-8b.c scan-tree-dump-times slp2 "basic block
vectorized"
1
FAIL: gcc.dg/vect/slp-cond-3.c -flto -ffat-lto-objects
scan-tree-dump-times vec
t "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-cond-3.c scan-tree-dump-times vect "vectorizing
stmts usin
g SLP" 1
Bah.
I suppose I need to investigate this (simply folding a stmt shouldn't
cause any of the above... - with SLP it is probably operand
canonicalization, but not sure).
Richard.
> Richard.
>
> Index: gcc/tree-ssa-forwprop.c
> ===================================================================
> --- gcc/tree-ssa-forwprop.c (revision 216258)
> +++ gcc/tree-ssa-forwprop.c (working copy)
> @@ -54,6 +54,8 @@ along with GCC; see the file COPYING3.
> #include "tree-ssa-propagate.h"
> #include "tree-ssa-dom.h"
> #include "builtins.h"
> +#include "tree-cfgcleanup.h"
> +#include "tree-into-ssa.h"
>
> /* This pass propagates the RHS of assignment statements into use
> sites of the LHS of the assignment. It's basically a specialized
> @@ -3586,6 +3588,8 @@ simplify_mult (gimple_stmt_iterator *gsi
>
> return false;
> }
> +
> +
> /* Main entry point for the forward propagation and statement combine
> optimizer. */
>
> @@ -3626,6 +3630,40 @@ pass_forwprop::execute (function *fun)
>
> cfg_changed = false;
>
> + /* Combine stmts with the stmts defining their operands. Do that
> + in an order that guarantees visiting SSA defs before SSA uses. */
> + int *postorder = XNEWVEC (int, n_basic_blocks_for_fn (fun));
> + int postorder_num = inverted_post_order_compute (postorder);
> + for (int i = 0; i < postorder_num; ++i)
> + {
> + bb = BASIC_BLOCK_FOR_FN (fun, postorder[i]);
> + for (gimple_stmt_iterator gsi = gsi_start_bb (bb);
> + !gsi_end_p (gsi); gsi_next (&gsi))
> + {
> + gimple stmt = gsi_stmt (gsi);
> + gimple orig_stmt = stmt;
> +
> + if (fold_stmt (&gsi))
> + {
> + stmt = gsi_stmt (gsi);
> + if (maybe_clean_or_replace_eh_stmt (orig_stmt, stmt)
> + && gimple_purge_dead_eh_edges (bb))
> + cfg_changed = true;
> + update_stmt (stmt);
> + }
> + }
> + }
> + free (postorder);
> +
> + /* ??? Code below doesn't expect non-renamed VOPs and the above
> + doesn't keep virtual operand form up-to-date. */
> + if (cfg_changed)
> + {
> + cleanup_tree_cfg ();
> + cfg_changed = false;
> + }
> + update_ssa (TODO_update_ssa_only_virtuals);
> +
> FOR_EACH_BB_FN (bb, fun)
> {
> gimple_stmt_iterator gsi;
>
--
Richard Biener <rguenther@suse.de>
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer