From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26669 invoked by alias); 31 Oct 2012 12:04:10 -0000 Received: (qmail 26661 invoked by uid 22791); 31 Oct 2012 12:04:10 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,TW_TM X-Spam-Check-By: sourceware.org Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 31 Oct 2012 12:04:00 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 3F907543BC4; Wed, 31 Oct 2012 13:03:59 +0100 (CET) Date: Wed, 31 Oct 2012 12:06:00 -0000 From: Jan Hubicka To: Richard Biener Cc: Jan Hubicka , gcc-patches@gcc.gnu.org Subject: Re: Non-dominating loop bounds in tree-ssa-loop-niter 3/4 Message-ID: <20121031120359.GA13132@kam.mff.cuni.cz> References: <20121031103949.GD19020@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-10/txt/msg02898.txt.bz2 > > 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