From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9314 invoked by alias); 9 May 2009 20:07:15 -0000 Received: (qmail 9225 invoked by uid 22791); 9 May 2009 20:07:14 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,SARE_LWSHORTT X-Spam-Check-By: sourceware.org Received: from mail3-relais-sop.national.inria.fr (HELO mail3-relais-sop.national.inria.fr) (192.134.164.104) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 09 May 2009 20:07:08 +0000 Received: from versailles.c0hen.net (HELO [192.168.0.3]) ([82.240.29.21]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 May 2009 22:07:04 +0200 Message-ID: <4A05E28A.3090306@inria.fr> Date: Sat, 09 May 2009 20:20:00 -0000 From: Albert Cohen User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: GCC CC: Albert Cohen Subject: Interest in integer auto-upcasting pass for normalization and optimization? Content-Type: text/plain; charset=ISO-8859-15; format=flowed 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/msg00243.txt.bz2 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. Feedback welcome, Albert