From: Richard Guenther <rguenther@suse.de>
To: Sebastian Pop <sebpop@gmail.com>
Cc: gcc-patches@gcc.gnu.org, matz@suse.de
Subject: Re: [PATCH 1/4] Add flag -ftree-loop-if-convert-memory-writes.
Date: Mon, 16 Aug 2010 09:46:00 -0000 [thread overview]
Message-ID: <alpine.LNX.2.00.1008161142100.28912@zhemvz.fhfr.qr> (raw)
In-Reply-To: <AANLkTikcJOR40zBJLFrTUwzkWvL03aCZNy6UoFmY49iQ@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2904 bytes --]
On Fri, 13 Aug 2010, Sebastian Pop wrote:
> On Fri, Aug 13, 2010 at 03:54, Richard Guenther <rguenther@suse.de> wrote:
> >> +static void
> >> +predicate_mem_writes (loop_p loop)
> >> +{
> >> + Â unsigned int i, orig_loop_num_nodes = loop->num_nodes;
> >> +
> >> + Â for (i = 1; i < orig_loop_num_nodes; i++)
> >> + Â Â {
> >> + Â Â Â gimple_stmt_iterator gsi;
> >> + Â Â Â basic_block bb = ifc_bbs[i];
> >> + Â Â Â tree cond = bb_predicate (bb);
> >> +
> >> + Â Â Â if (is_true_predicate (cond))
> >> + Â Â continue;
> >> +
> >> + Â Â Â for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
> >
> > So this is another loop over all loops and statements. Â Why not
> > do this loop once and dispatch to mem/scalar if-conversion there?
> >
> >> @@ -1178,7 +1270,10 @@ combine_blocks (struct loop *loop)
> >>
> >> Â Â remove_conditions_and_labels (loop);
> >> Â Â insert_gimplified_predicates (loop);
> >> - Â ifconvert_phi_nodes (loop);
> >> + Â predicate_all_scalar_phis (loop);
> >> +
> >> + Â if (flag_tree_loop_if_convert_memory_writes)
> >> + Â Â predicate_mem_writes (loop);
> >
> > As suggested above, predicate_all_scalar_phis and predicate_mem_writes
> > should loop over all loops/bbs once.
> >
>
> The only thing that predicate_all_scalar_phis and predicate_mem_writes
> have in common is that they iterate over all the basic blocks of an
> innermost loop.
>
> predicate_mem_writes iterates over all the statements of the BB.
>
> predicate_all_scalar_phis iterates over all the phi nodes of the BB.
>
> Should I go ahead and merge these two functions as asked?
> I still find the implementation more clear in the separated form.
Yeah, thinking again it's ok as-is.
> Please find attached a preliminary patch (passed compile and
> make -k check RUNTESTFLAGS=tree-ssa.exp and vect.exp) on top of
> the previous one, that shows the corrections for all your comments
> (except this last point). I will submit the combined patch +
> corrections once it passes bootstrap and test.
- || gimple_code (gsi_stmt (gsi)) == GIMPLE_COND)
+ || gimple_code (gsi_stmt (gsi)) == GIMPLE_COND
+ || stmt_ends_bb_p (gsi_stmt (gsi)))
GIMPLE_CONDs already are handled in stmt_ends_bb_p, so the check
for GIMPLE_COND can be removed.
@@ -1628,7 +1716,7 @@ main_tree_if_conversion (void)
changed |= tree_if_conversion (loop);
if (changed && flag_tree_loop_if_convert_memory_writes)
- update_ssa (TODO_update_ssa);
+ return TODO_update_ssa_only_virtuals;
return changed ? TODO_cleanup_cfg : 0;
So you skip cfg_cleanup in that case. I'd have done
unsigned todo = 0;
...
if (changed)
todo |= TODO_cleanup_cfg;
if (changed && flag_tree_loop_if_convert_memory_writes)
todo |= TODO_update_ssa_only_virtuals;
return todo;
I'll wait for a new combined patch and have a quick look at it.
Richard.
next prev parent reply other threads:[~2010-08-16 9:46 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-08 21:41 [PATCH 0/4] if-conversion of loops with conditionals containing memory writes Sebastian Pop
2010-07-08 21:41 ` [PATCH 2/4] Outline fold_or_predicates from add_to_predicate_list Sebastian Pop
2010-07-09 12:13 ` Richard Guenther
2010-07-09 16:43 ` Sebastian Pop
2010-07-09 17:04 ` Sebastian Pop
2010-07-09 18:25 ` Richard Guenther
2010-07-09 18:59 ` Sebastian Pop
2010-07-08 21:42 ` [PATCH 4/4] Speed-up ifcvt_memrefs_wont_trap caching previous results Sebastian Pop
2010-08-13 9:02 ` Richard Guenther
2010-07-08 21:42 ` [PATCH 3/4] Do not check whether memory references accessed in every iteration trap Sebastian Pop
2010-08-13 9:41 ` Richard Guenther
2010-08-17 17:18 ` Sebastian Pop
2010-08-18 9:35 ` Richard Guenther
2010-08-18 17:10 ` Sebastian Pop
2010-08-18 19:05 ` Richard Guenther
2010-08-18 19:29 ` [PATCH 2/3] " Sebastian Pop
2010-08-18 19:29 ` [PATCH 3/3] Speed-up ifcvt_memrefs_wont_trap caching previous results Sebastian Pop
2010-08-18 19:31 ` [PATCH 1/3] Add flag -ftree-loop-if-convert-memory-writes Sebastian Pop
2010-08-18 19:32 ` [PATCH 3/4] Do not check whether memory references accessed in every iteration trap Sebastian Pop
2010-08-24 10:26 ` Richard Guenther
2010-08-24 15:47 ` Sebastian Pop
2010-08-24 16:31 ` Sebastian Pop
2010-09-20 7:44 ` Gerald Pfeifer
2010-07-08 21:42 ` [PATCH 1/4] Add flag -ftree-loop-if-convert-memory-writes Sebastian Pop
2010-08-13 8:58 ` Richard Guenther
2010-08-13 20:43 ` Sebastian Pop
2010-08-16 9:46 ` Richard Guenther
2010-08-13 22:12 ` Sebastian Pop
2010-08-16 9:46 ` Richard Guenther [this message]
2010-08-13 22:22 ` Sebastian Pop
2010-08-16 9:53 ` Richard Guenther
2010-08-12 16:19 ` [PATCH 0/4] if-conversion of loops with conditionals containing memory writes Sebastian Pop
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LNX.2.00.1008161142100.28912@zhemvz.fhfr.qr \
--to=rguenther@suse.de \
--cc=gcc-patches@gcc.gnu.org \
--cc=matz@suse.de \
--cc=sebpop@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).