public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <aoliva@redhat.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PR68083] stop ifcombine from moving uninitialized uses before their guards
Date: Fri, 30 Oct 2015 18:03:00 -0000	[thread overview]
Message-ID: <or37wsfd4d.fsf@livre.home> (raw)
In-Reply-To: <or8u6kfp8l.fsf@livre.home> (Alexandre Oliva's message of "Fri,	30 Oct 2015 11:41:14 -0200")

On Oct 30, 2015, Alexandre Oliva <aoliva@redhat.com> wrote:

> Incidentally, bb_no_side_effects_p (inner_cond_bb) is called in all four
> tests in tree_ssa_ifcombine_bb_1, for each outer_cond_bb that
> tree_ssa_ifcombine_bb might choose.  Is there any reason to not factor
> it out to the test that checks whether the inner_cond_bb is indeed an
> if_then_else block, early in tree_ssa_ifcombine_bb, so as to
> short-circuit the whole thing when the inner block is not viable?

Like this...

Bail out early if the inner block has side effects or is otherwise not
eligible for ifcombine.

Regstrapped on x86_64-linux-gnu.  Ok to install?


for  gcc/ChangeLog

	* tree-ssa-ifcombine.c (tree_ssa_ifcombine_bb_1): Factor out
	bb_no_side_effects_p tests...
	(tree_ssa_ifcombine_bb): ... here.
---
 gcc/tree-ssa-ifcombine.c |   15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/gcc/tree-ssa-ifcombine.c b/gcc/tree-ssa-ifcombine.c
index 622dc6b..3b60968 100644
--- a/gcc/tree-ssa-ifcombine.c
+++ b/gcc/tree-ssa-ifcombine.c
@@ -579,8 +579,7 @@ tree_ssa_ifcombine_bb_1 (basic_block inner_cond_bb, basic_block outer_cond_bb,
      the inner cond_bb having no side-effects.  */
   if (phi_pred_bb != else_bb
       && recognize_if_then_else (outer_cond_bb, &inner_cond_bb, &else_bb)
-      && same_phi_args_p (outer_cond_bb, phi_pred_bb, else_bb)
-      && bb_no_side_effects_p (inner_cond_bb))
+      && same_phi_args_p (outer_cond_bb, phi_pred_bb, else_bb))
     {
       /* We have
 	   <outer_cond_bb>
@@ -598,8 +597,7 @@ tree_ssa_ifcombine_bb_1 (basic_block inner_cond_bb, basic_block outer_cond_bb,
   /* And a version where the outer condition is negated.  */
   if (phi_pred_bb != else_bb
       && recognize_if_then_else (outer_cond_bb, &else_bb, &inner_cond_bb)
-      && same_phi_args_p (outer_cond_bb, phi_pred_bb, else_bb)
-      && bb_no_side_effects_p (inner_cond_bb))
+      && same_phi_args_p (outer_cond_bb, phi_pred_bb, else_bb))
     {
       /* We have
 	   <outer_cond_bb>
@@ -620,8 +618,7 @@ tree_ssa_ifcombine_bb_1 (basic_block inner_cond_bb, basic_block outer_cond_bb,
      having no side-effects.  */
   if (phi_pred_bb != then_bb
       && recognize_if_then_else (outer_cond_bb, &then_bb, &inner_cond_bb)
-      && same_phi_args_p (outer_cond_bb, phi_pred_bb, then_bb)
-      && bb_no_side_effects_p (inner_cond_bb))
+      && same_phi_args_p (outer_cond_bb, phi_pred_bb, then_bb))
     {
       /* We have
 	   <outer_cond_bb>
@@ -638,8 +635,7 @@ tree_ssa_ifcombine_bb_1 (basic_block inner_cond_bb, basic_block outer_cond_bb,
   /* And a version where the outer condition is negated.  */
   if (phi_pred_bb != then_bb
       && recognize_if_then_else (outer_cond_bb, &inner_cond_bb, &then_bb)
-      && same_phi_args_p (outer_cond_bb, phi_pred_bb, then_bb)
-      && bb_no_side_effects_p (inner_cond_bb))
+      && same_phi_args_p (outer_cond_bb, phi_pred_bb, then_bb))
     {
       /* We have
 	   <outer_cond_bb>
@@ -676,7 +672,8 @@ tree_ssa_ifcombine_bb (basic_block inner_cond_bb)
        if (a && b)
 	 ;
      This requires a single predecessor of the inner cond_bb.  */
-  if (single_pred_p (inner_cond_bb))
+  if (single_pred_p (inner_cond_bb)
+      && bb_no_side_effects_p (inner_cond_bb))
     {
       basic_block outer_cond_bb = single_pred (inner_cond_bb);
 


-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

  reply	other threads:[~2015-10-30 18:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-30 13:57 Alexandre Oliva
2015-10-30 18:03 ` Alexandre Oliva [this message]
2015-11-02  9:32   ` Richard Biener
2015-11-02  9:32 ` Richard Biener

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=or37wsfd4d.fsf@livre.home \
    --to=aoliva@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@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).