From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16683 invoked by alias); 9 May 2009 20:42:48 -0000 Received: (qmail 16623 invoked by uid 22791); 9 May 2009 20:42:47 -0000 X-SWARE-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL,BAYES_50,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-qy0-f126.google.com (HELO mail-qy0-f126.google.com) (209.85.221.126) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 09 May 2009 20:42:42 +0000 Received: by qyk32 with SMTP id 32so2720439qyk.0 for ; Sat, 09 May 2009 13:42:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.90.140 with SMTP id i12mr9501926vcm.22.1241901759705; Sat, 09 May 2009 13:42:39 -0700 (PDT) In-Reply-To: <4A05E28A.3090306@inria.fr> References: <4A05E28A.3090306@inria.fr> Date: Sat, 09 May 2009 22:28:00 -0000 Message-ID: <84fc9c000905091342o117cc8fbl3e6cac18ff39325d@mail.gmail.com> Subject: Re: Interest in integer auto-upcasting pass for normalization and optimization? From: Richard Guenther To: Albert Cohen Cc: GCC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-05/txt/msg00246.txt.bz2 On Sat, May 9, 2009 at 10:07 PM, Albert Cohen wrote: > Sebastian Pop and I have been discussing the option of designing a new pass, > based on vrp, to normalize integer types towards a canonical supertype > typically a machine word, equivalent to signed long, or to truncate to a > smaller-size word when it makes sense. This would be a very simple pass (on > top of not-so-simple vrp), but arguably a quite regression-prone one as well > (due to aliases/escape and common C standard violations). > > The pass could be parameterized with three different objectives, depending > on where it is scheduled in the pass manager. > > (1) canonicalize to the supertype aggressively, to facilitate the > application of further passes like autovect which require very precise > understanding of the type conversions; > (2) compress the types to increase vectorization factor and reduce register > pressure (assuming the target supports sub-word register allocation with > register aliases); > (3) optimize the types to minimize the dynamic number of casts that result > in actual ASM instructions. > > Graphite and the vectorizer would clearly benefit from such a pass, at least > if it implemented objective (1). > > I wonder if some of this is already implemented somewhere, or if someone > played with it in the past, or is interesting in contributing. > > Nothing is planned yet on our side, and temporary fixes exist in the short > term (as far as Graphite and the vectorizer are concerned), but it would > potentially be of great help. This is certainly one useful transformation based on value-range information. The choice of a canonical type is of course at least target dependent. I suppose you want to do this on register variables only? Did you think about promoting function arguments and returns as well as part of an IPA pass? I don't understand how register variable promotion/demotion will help graphite though - I had the impression graphite can only work on memory. No? Thanks, Richard.