From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14056 invoked by alias); 1 Sep 2011 14:41:00 -0000 Received: (qmail 13998 invoked by uid 22791); 1 Sep 2011 14:40:58 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 01 Sep 2011 14:40:43 +0000 Received: by wwi18 with SMTP id 18so1823516wwi.8 for ; Thu, 01 Sep 2011 07:40:42 -0700 (PDT) Received: by 10.216.143.211 with SMTP id l61mr294646wej.5.1314888042257; Thu, 01 Sep 2011 07:40:42 -0700 (PDT) Received: from richards-thinkpad.stglab.manchester.uk.ibm.com (gbibp9ph1--blueice2n1.emea.ibm.com [195.212.29.75]) by mx.google.com with ESMTPS id 51sm77840wel.20.2011.09.01.07.40.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Sep 2011 07:40:41 -0700 (PDT) From: Richard Sandiford To: Michael Matz Mail-Followup-To: Michael Matz ,Ira Rosen , Richard Guenther , gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org Cc: Ira Rosen , Richard Guenther , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Make vectorizer dumps more comparable References: Date: Thu, 01 Sep 2011 14:41:00 -0000 In-Reply-To: (Michael Matz's message of "Thu, 1 Sep 2011 15:41:36 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00068.txt.bz2 Michael Matz writes: >> 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? I suppose it's just personal preference. I look at the dumps using less, and search for the line number. That highlights all the lines in the loop I care about. It just seemed like a very nice visual cue when the relevant part of the dump was longer than a page. Richard