From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121792 invoked by alias); 15 Aug 2016 20:06:14 -0000 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 Received: (qmail 121775 invoked by uid 89); 15 Aug 2016 20:06:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy= X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 15 Aug 2016 20:06:12 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 0277D5440E4; Mon, 15 Aug 2016 22:06:09 +0200 (CEST) Date: Mon, 15 Aug 2016 20:06:00 -0000 From: Jan Hubicka To: Jeff Law Cc: Jan Hubicka , James Greenhalgh , Andrew Pinski , GCC Patches , nd@arm.com Subject: Re: backward threading heuristics tweek Message-ID: <20160815200609.GA26405@kam.mff.cuni.cz> References: <20160606101953.GC12313@kam.mff.cuni.cz> <20160808082830.GA14494@arm.com> <20160811123558.GB67433@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.21 (2010-09-15) X-SW-Source: 2016-08/txt/msg01145.txt.bz2 > >So the threaded path lives fully inside loop1: 6->8->9->3->4->6 propagating > >that phi_inserted is 0 after the first iteration of the loop. This looks like > >useful loop peeling oppurtunity which does not garble loop structure. So > >perhaps threading paths starting and passing loop latch (i.e. peeling) is > >sane? Perhaps all paths fully captured in the loop in question are? > Peeling like this has long been a point of contention -- it totally > mucks things up like vectorizing. > > The general issue that the threader knows nothing about the > characteristics of the loop -- thus peeling is at this point is > premature and just as likely to hinder performance as improve it. > > I'm never been happy with how this aspect of threading vs loop opts > turned out and we have open BZs related to this rats nest of issues. Ok, then we perhaps just want to silence the testcase? Honza > > jeff >