public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: Richard Biener <rguenther@suse.de>
Cc: Jan Hubicka <hubicka@ucw.cz>, gcc-patches@gcc.gnu.org
Subject: Re: Non-dominating loop bounds in tree-ssa-loop-niter 3/4
Date: Wed, 31 Oct 2012 12:06:00 -0000	[thread overview]
Message-ID: <20121031120359.GA13132@kam.mff.cuni.cz> (raw)
In-Reply-To: <alpine.LNX.2.00.1210311156460.4063@zhemvz.fhfr.qr>

> > Index: tree-ssa-loop-niter.c
> > ===================================================================
> > --- tree-ssa-loop-niter.c	(revision 192989)
> > @@ -3505,15 +3737,11 @@ scev_probably_wraps_p (tree base, tree s
> >    return true;
> >  }
> >  
> > -/* Frees the information on upper bounds on numbers of iterations of LOOP.  */
> > -
> 
> Needs a comment.

Yep,
also the reason I export it is because I use in other patch.
(I think we should not hook the bounds into the loop structure and keep them dead,
so i want the max_iter*friends to free them unless they are asked to preserve and
explicitely free in the two users of them).
> > +static bool
> > +remove_exits_and_undefined_stmts (struct loop *loop, unsigned int npeeled)
> > +{
> > +  struct nb_iter_bound *elt;
> > +  bool changed = false;
> > +
> > +  for (elt = loop->bounds; elt; elt = elt->next)
> > +    {
> > +      /* If statement is known to be undefined after peeling, turn it
> > +	 into unreachable (or trap when debugging experience is supposed
> > +	 to be good).  */
> > +      if (!elt->is_exit
> > +	  && elt->bound.ule (double_int::from_uhwi (npeeled)))
> > +	{
> > +	  gimple_stmt_iterator gsi = gsi_for_stmt (elt->stmt);
> > +	  gimple stmt = gimple_build_call
> > +	      (builtin_decl_implicit (optimize_debug
> > +				      ? BUILT_IN_TRAP : BUILT_IN_UNREACHABLE),
> 
> I'm not sure we should do different things for -Og here.  In fact there
> is no unrolling done for -Og at all, so just use unreachable.

OK, I was thinking about BUILT_IN_TRAP for -O1 too, but I am not sure either.
i guess we will gather some experience on how much are users confused.

Why we do ont inline at -Og?
> > +      /* If we know the exit will be taken after peeling, update.  */
> > +      else if (elt->is_exit
> > +	       && elt->bound.ule (double_int::from_uhwi (npeeled)))
> > +	{
> > +	  basic_block bb = gimple_bb (elt->stmt);
> > +	  edge exit_edge = EDGE_SUCC (bb, 0);
> > +
> > +	  if (dump_file && (dump_flags & TDF_DETAILS))
> > +	    {
> > +	      fprintf (dump_file, "Forced exit to be taken: ");
> > +	      print_gimple_stmt (dump_file, elt->stmt, 0, 0);
> > +	    }
> > +	  if (!loop_exit_edge_p (loop, exit_edge))
> > +	    exit_edge = EDGE_SUCC (bb, 1);
> > +	  if (exit_edge->flags & EDGE_TRUE_VALUE)
> 
> I think we can have abnormal/eh exit edges.  So I'm not sure you
> can, without checking, assume the block ends in a GIMPLE_COND.

We can't - those are only edges that are found by the IV analysis and they
always test IV with some bound. (it is all done by number_of_iterations_exit)
> 
> See above.  Otherwise the overall idea sounds fine.

Similarly here, simple exits are always conditionals. 


Thanks a lot!
Honza

  reply	other threads:[~2012-10-31 12:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-31 10:46 Jan Hubicka
2012-10-31 11:23 ` Richard Biener
2012-10-31 12:06   ` Jan Hubicka [this message]
2012-10-31 12:22     ` Richard Biener
2012-10-31 12:31       ` Jan Hubicka
2012-10-31 12:34         ` Richard Biener
2012-10-31 12:36           ` Jakub Jelinek
2012-10-31 12:45             ` Richard Biener
2012-10-31 14:18             ` Jan Hubicka
2012-10-31 14:07               ` Richard Biener
2012-12-01 19:22 ` H.J. Lu

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=20121031120359.GA13132@kam.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=rguenther@suse.de \
    /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).