public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Razya Ladelsky <RAZYA@il.ibm.com>
To: Zdenek Dvorak <rakdver@kam.mff.cuni.cz>
Cc: gcc-patches@gcc.gnu.org, Richard Guenther <richard.guenther@gmail.com>
Subject: Re: PATCH] PR 49580
Date: Tue, 05 Jul 2011 11:09:00 -0000	[thread overview]
Message-ID: <OFE6839880.43848297-ONC22578C4.003C958B-C22578C4.003D75D7@il.ibm.com> (raw)
In-Reply-To: <20110705103741.GA9127@kam.mff.cuni.cz>

[-- Attachment #1: Type: text/plain, Size: 5991 bytes --]

Zdenek Dvorak <rakdver@kam.mff.cuni.cz> wrote on 05/07/2011 13:37:41:

> From: Zdenek Dvorak <rakdver@kam.mff.cuni.cz>
> To: Razya Ladelsky/Haifa/IBM@IBMIL
> Cc: gcc-patches@gcc.gnu.org, Richard Guenther 
<richard.guenther@gmail.com>
> Date: 05/07/2011 13:37
> Subject: Re: PATCH] PR 49580
> 
> Hi,
> 
> > I moved the adjustment of the loop's iterations from 
> > gimple_duplicate_sese_tail
> > to tree-parloops.c, right before the call to 
gimple_duplicate_sese_tail.
> > I repeated the bootstrap, regression and spec runs - no new 
regressions.
> > 
> > OK to commit?
> 
> OK,
> 
> Zdenek

I also want to commit this testcase, which is a reduced case of the gcc 
benchmark.
I apologize for not submitting it together with the patch.
OK?

Thanks,
Razya




> 
> > Index: gcc/tree-parloops.c
> > ===================================================================
> > --- gcc/tree-parloops.c   (revision 174166)
> > +++ gcc/tree-parloops.c   (working copy)
> > @@ -1464,6 +1464,8 @@ transform_to_exit_first_loop (struct loop *loop, 
h
> >    gimple phi, nphi, cond_stmt, stmt, cond_nit;
> >    gimple_stmt_iterator gsi;
> >    tree nit_1;
> > +  edge exit_1;
> > +  tree new_rhs;
> > 
> >    split_block_after_labels (loop->header);
> >    orig_header = single_succ (loop->header);
> > @@ -1492,6 +1494,38 @@ transform_to_exit_first_loop (struct loop 
*loop, h
> >       control = t;
> >     }
> >      }
> > +
> > + /* Setting the condition towards peeling the last iteration:
> > +    If the block consisting of the exit condition has the latch as
> > +    successor, then the body of the loop is executed before
> > +    the exit condition is tested.  In such case, moving the
> > +    condition to the entry, causes that the loop will iterate
> > +    one less iteration (which is the wanted outcome, since we
> > +    peel out the last iteration).  If the body is executed after
> > +    the condition, moving the condition to the entry requires
> > +    decrementing one iteration.  */
> > +  exit_1 = EDGE_SUCC (exit->src, EDGE_SUCC (exit->src, 0) == exit); 
> > +  if (exit_1->dest == loop->latch)
> > +    new_rhs = gimple_cond_rhs (cond_stmt);
> > +  else
> > +  {
> > +    new_rhs = fold_build2 (MINUS_EXPR, TREE_TYPE (gimple_cond_rhs
> (cond_stmt)),
> > +            gimple_cond_rhs (cond_stmt),
> > +            build_int_cst (TREE_TYPE (gimple_cond_rhs (cond_stmt)), 
1));
> > +    if (TREE_CODE (gimple_cond_rhs (cond_stmt)) == SSA_NAME)
> > +      {
> > +    basic_block preheader;
> > +     gimple_stmt_iterator gsi1;
> > +
> > +     preheader = loop_preheader_edge(loop)->src;
> > +       gsi1 = gsi_after_labels (preheader);
> > +   new_rhs = force_gimple_operand_gsi (&gsi1, new_rhs, true,
> > +                   NULL_TREE,false,GSI_CONTINUE_LINKING);
> > +      }
> > +  }
> > +  gimple_cond_set_rhs (cond_stmt, unshare_expr (new_rhs));
> > +  gimple_cond_set_lhs (cond_stmt, unshare_expr (gimple_cond_lhs 
> (cond_stmt)));
> > + 
> >    bbs = get_loop_body_in_dom_order (loop);
> > 
> >    for (n = 0; bbs[n] != loop->latch; n++)
> > Index: gcc/tree-cfg.c
> > ===================================================================
> > --- gcc/tree-cfg.c   (revision 174166)
> > +++ gcc/tree-cfg.c   (working copy)
> > @@ -5397,12 +5397,10 @@ gimple_duplicate_sese_tail (edge entry 
ATTRIBUTE_U
> >    int total_freq = 0, exit_freq = 0;
> >    gcov_type total_count = 0, exit_count = 0;
> >    edge exits[2], nexits[2], e;
> > -  gimple_stmt_iterator gsi,gsi1;
> > +  gimple_stmt_iterator gsi;
> >    gimple cond_stmt;
> >    edge sorig, snew;
> >    basic_block exit_bb;
> > -  basic_block iters_bb;
> > -  tree new_rhs;
> >    gimple_stmt_iterator psi;
> >    gimple phi;
> >    tree def;
> > @@ -5483,35 +5481,6 @@ gimple_duplicate_sese_tail (edge entry 
ATTRIBUTE_U
> >    gcc_assert (gimple_code (cond_stmt) == GIMPLE_COND);
> >    cond_stmt = gimple_copy (cond_stmt);
> > 
> > - /* If the block consisting of the exit condition has the latch as
> > -    successor, then the body of the loop is executed before
> > -    the exit condition is tested.  In such case, moving the
> > -    condition to the entry, causes that the loop will iterate
> > -    one less iteration (which is the wanted outcome, since we
> > -    peel out the last iteration).  If the body is executed after
> > -    the condition, moving the condition to the entry requires
> > -    decrementing one iteration.  */
> > -  if (exits[1]->dest == orig_loop->latch)
> > -    new_rhs = gimple_cond_rhs (cond_stmt);
> > -  else
> > -  {
> > -    new_rhs = fold_build2 (MINUS_EXPR, TREE_TYPE (gimple_cond_rhs
> (cond_stmt)),
> > -            gimple_cond_rhs (cond_stmt),
> > -            build_int_cst (TREE_TYPE (gimple_cond_rhs (cond_stmt)), 
1));
> > -
> > -    if (TREE_CODE (gimple_cond_rhs (cond_stmt)) == SSA_NAME)
> > -      {
> > -   iters_bb = gimple_bb (SSA_NAME_DEF_STMT (gimple_cond_rhs 
(cond_stmt)));
> > -   for (gsi1 = gsi_start_bb (iters_bb); !gsi_end_p (gsi1); 
> gsi_next (&gsi1))
> > -     if (gsi_stmt (gsi1) == SSA_NAME_DEF_STMT (gimple_cond_rhs 
> (cond_stmt)))
> > -       break;
> > -
> > -   new_rhs = force_gimple_operand_gsi (&gsi1, new_rhs, true,
> > -                   NULL_TREE,false,GSI_CONTINUE_LINKING);
> > -      }
> > -  }
> > -  gimple_cond_set_rhs (cond_stmt, unshare_expr (new_rhs));
> > -  gimple_cond_set_lhs (cond_stmt, unshare_expr (gimple_cond_lhs 
> (cond_stmt)));
> >    gsi_insert_after (&gsi, cond_stmt, GSI_NEW_STMT);
> > 
> >    sorig = single_succ_edge (switch_bb);
> 
> > 
> > 07-05-2011  Razya Ladelsky  <razya@il.ibm.com>
> > 
> >    * tree-cfg.c (gimple_duplicate_sese_tail): Remove handling of 
> >    the loop's number of iterations.
> >         * tree-parloops.c (transform_to_exit_first_loop): Add the 
> >    handling of the loop's number of iterations before the call 
> >    to gimple_duplicate_sese_tail.
> >         Insert the stmt caclculating the new rhs of the loop's
> >    condition stmt to the preheader instead of iters_bb.
> 

[-- Attachment #2: gcc_test.c --]
[-- Type: application/octet-stream, Size: 886 bytes --]

/* { dg-do compile } */
/* { dg-options "-O2 -ftree-parallelize-loops=4 -fdump-tree-parloops-details -fdump-tree-optimized" } */

#include <stdarg.h>
#include <stdlib.h>

#define N 1600

unsigned int ub[N];
unsigned char reg_has_output_reload[N];
unsigned int uc[N];

 __attribute__ ((noinline)) 
 void main2 (unsigned int regno, unsigned int n_reloads)
 {
  unsigned int nr = 0;

  if (regno > ub[regno])
    nr = regno;
  else
    nr = ub[nr];

  while (nr-- > 0)
    if (n_reloads == 0 || reg_has_output_reload[regno + nr] == 0)
      ub[regno + nr] = 0;
}

int main (void)
{ 
  main2 (799, 0);
  return 0;
}


/* { dg-final { scan-tree-dump-times "Detected reduction" 3 "parloops" } } */
/* { dg-final { scan-tree-dump-times "SUCCESS: may be parallelized" 4 "parloops" } } */
/* { dg-final { cleanup-tree-dump "parloops" } } */
/* { dg-final { cleanup-tree-dump "optimized" } } */


  reply	other threads:[~2011-07-05 11:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-30 13:15 Razya Ladelsky
2011-06-30 13:16 ` Richard Guenther
2011-06-30 13:20 ` Zdenek Dvorak
2011-06-30 14:40   ` Razya Ladelsky
2011-07-05 10:38   ` Razya Ladelsky
2011-07-05 11:08     ` Zdenek Dvorak
2011-07-05 11:09       ` Razya Ladelsky [this message]
2011-07-05 11:20         ` Richard Guenther

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=OFE6839880.43848297-ONC22578C4.003C958B-C22578C4.003D75D7@il.ibm.com \
    --to=razya@il.ibm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=rakdver@kam.mff.cuni.cz \
    --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).