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
next prev parent 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).