From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14296 invoked by alias); 31 Oct 2012 12:22:57 -0000 Received: (qmail 14281 invoked by uid 22791); 31 Oct 2012 12:22:56 -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 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:22:35 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 6BF84543BD0; Wed, 31 Oct 2012 13:22:34 +0100 (CET) Date: Wed, 31 Oct 2012 12:31: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: <20121031122234.GA15866@kam.mff.cuni.cz> References: <20121031103949.GD19020@kam.mff.cuni.cz> <20121031120359.GA13132@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/msg02907.txt.bz2 > > unroll you mean. Because unrolling mutates the CFG too much. > Well - it was just a starting point, populating -Og with as little > as possible and 100% profitable transforms (in both debug and speed > metric). In late opts we only do (early opt queue is shared): Well, and what about early cunrolli? > > NEXT_PASS (pass_all_optimizations_g); > { > struct opt_pass **p = &pass_all_optimizations_g.pass.sub; > NEXT_PASS (pass_remove_cgraph_callee_edges); > NEXT_PASS (pass_strip_predict_hints); > /* Lower remaining pieces of GIMPLE. */ > NEXT_PASS (pass_lower_complex); > NEXT_PASS (pass_lower_vector_ssa); > /* Perform simple scalar cleanup which is constant/copy propagation. > */ > NEXT_PASS (pass_ccp); > NEXT_PASS (pass_object_sizes); > /* Copy propagation also copy-propagates constants, this is > necessary > to forward object-size results properly. */ > NEXT_PASS (pass_copy_prop); > NEXT_PASS (pass_rename_ssa_copies); > NEXT_PASS (pass_dce); > /* Fold remaining builtins. */ > NEXT_PASS (pass_fold_builtins); > /* ??? We do want some kind of loop invariant motion, but we > possibly > need to adjust LIM to be more friendly towards preserving > accurate > debug information here. */ > NEXT_PASS (pass_late_warn_uninitialized); > NEXT_PASS (pass_uncprop); > NEXT_PASS (pass_local_pure_const); > } > > > > > + /* 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. > > I see. Then the patch is ok (with the comment added). Thanks, i will ad comment and privatize free_loop_bounds for now. Honza > > Thanks, > Richard.