From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1916 invoked by alias); 1 Sep 2011 13:41:54 -0000 Received: (qmail 1905 invoked by uid 22791); 1 Sep 2011 13:41:52 -0000 X-SWARE-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 01 Sep 2011 13:41:38 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.221.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id BC3408EEDE; Thu, 1 Sep 2011 15:41:36 +0200 (CEST) Date: Thu, 01 Sep 2011 13:41:00 -0000 From: Michael Matz To: Richard Sandiford Cc: Ira Rosen , Richard Guenther , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Make vectorizer dumps more comparable In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes 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: 2011-09/txt/msg00062.txt.bz2 Hi, On Thu, 1 Sep 2011, Richard Sandiford wrote: > Ira Rosen writes: > >> How about, as Micha suggested, print the location of the loop > >> we currently investigate from vectorize_loops () where we > >> call find_loop_location () instead? > > > > The problem is that a dump of a single loop can be pretty long, and "start > > to analyze loop..."/"finish to analyze loop..." may be not visible enough. > > I am OK with adding these printings though (in addition to line numbers). > > > > I understand why you didn't like to see the file location, but what's the > > problem with the line number? > > +1 FWIW. I found these per-line locations really useful when doing > the strided load/store stuff. Really? Because the dumper always prints the location of the loop (i.e. its first line), not the location of the individual statements. Therefore anything searching for file:line number will match all lines connected with dealing with one loop, there's no differentiation between them. And hence I also don't see Iras point. Searching for file:line from file start before Richis changes would get you to the start where the loop is dealt with, and then not a bit further because all lines would be so prefixed. Searching from file end would get you to the end of the loop processing (with the final decision), and also not further because of the same prefix everywhere. So, no, I don't see how to prefix every line with the same prefix provides anything useful. Can you show me how it was useful to you? (Or you Ira?) FWIW my proposal would have been to do this: file:123 starting loop so-and-so ... unprefixed lines all dealing with this loop file:123 finished loop so-and-so Ciao, Michael.