From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32074 invoked by alias); 11 Apr 2011 14:09:28 -0000 Received: (qmail 32065 invoked by uid 22791); 11 Apr 2011 14:09:26 -0000 X-SWARE-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00,T_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; Mon, 11 Apr 2011 14:09:19 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.221.2]) by mx2.suse.de (Postfix) with ESMTP id ADBC3867E2; Mon, 11 Apr 2011 16:09:18 +0200 (CEST) Date: Mon, 11 Apr 2011 14:09:00 -0000 From: Richard Guenther To: Eric Botcazou Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Remove VRPs use of TYPE_MIN/MAX_VALUE In-Reply-To: <201104111522.39216.ebotcazou@adacore.com> Message-ID: References: <201104111522.39216.ebotcazou@adacore.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) 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-04/txt/msg00756.txt.bz2 On Mon, 11 Apr 2011, Eric Botcazou wrote: > > The middle-end treats conversions between integral types that differ > > in TYPE_MIN/MAX_VALUE but not in TYPE_PRECISION or signedness as useless. > > This is inconsistent with VRP extracting range information from such > > types (and it is not clear how NOP conversions behave here anyway). > > IIRC we agreed, by the time I fixed the Ada compiler, that the IL shouldn't > contain types with non-canonical bounds, except for constructs that don't > generate code like the TYPE_DOMAIN of arrays. My understanding is that this > has been the case (modulo bugs) for some time now, so I don't understand your > remark about NOP conversions. Such types are still there for enumeral type kinds. Also the C family frontends leak arithmetic in array TYPE_DOMAIN types. > > The following patch thus simply removes VRPs looking at TYPE_MIN/MAX_VALUE > > in favor of using a canonical min/max value based on signedness and > > precision. This exposes a latent bug in upper_bound_in_type and > > lower_bound_in_type which do not properly sign-extend sizetype constants. > > Wouldn't it be better performance-wise to keep using TYPE_MIN/MAX_VALUE and add > an appropriate check for non-standard types at the end of gimplification? I don't see how we can do this for ENUM types. We use the TYPE_MIN/MAX_VALUEs for debug information. I tried to assert this for INTEGER_TYPEs only, but as noted above the C family leaks TYPE_DOMAIN arithmetic. Richard.