From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4112 invoked by alias); 15 Oct 2007 13:17:52 -0000 Received: (qmail 4100 invoked by uid 22791); 15 Oct 2007 13:17:51 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.183) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 15 Oct 2007 13:17:48 +0000 Received: by py-out-1112.google.com with SMTP id a29so3695834pyi for ; Mon, 15 Oct 2007 06:17:46 -0700 (PDT) Received: by 10.64.179.12 with SMTP id b12mr11742884qbf.1192454266037; Mon, 15 Oct 2007 06:17:46 -0700 (PDT) Received: by 10.65.203.7 with HTTP; Mon, 15 Oct 2007 06:17:45 -0700 (PDT) Message-ID: <84fc9c000710150617t27aaa9ecj7037b386ca1c61f1@mail.gmail.com> Date: Mon, 15 Oct 2007 13:27:00 -0000 From: "Richard Guenther" To: "Richard Kenner" Subject: Re: [PATCH] Fix optimization regression in constant folder Cc: matz@suse.de, ebotcazou@adacore.com, gcc-patches@gcc.gnu.org, iant@google.com, mark@codesourcery.com In-Reply-To: <10710151056.AA28470@vlsi1.ultra.nyu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200709171539.26653.ebotcazou@adacore.com> <10710120240.AA03734@vlsi1.ultra.nyu.edu> <200710141225.08559.ebotcazou@adacore.com> <84fc9c000710140331t5b1bf94cr3a19b395c19faa22@mail.gmail.com> <10710141128.AA13909@vlsi1.ultra.nyu.edu> <84fc9c000710140608r6e86aa58wdacfb9e91cbbb3b8@mail.gmail.com> <10710150007.AA21358@vlsi1.ultra.nyu.edu> <10710151056.AA28470@vlsi1.ultra.nyu.edu> 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: 2007-10/txt/msg00885.txt.bz2 On 10/15/07, Richard Kenner wrote: > > we know that sizetypes _definitely_ are a problem for the middle-end > > because of their peculiar semantics. > > That may be, but those are the properties and semantics that they such > objects DO have from a conceptual point of view and any other way we > do it they would have the same semantics! (I'm not saying this very > well, but what I'm trying to say is that those semantics are intrinsic > to the type of calculations that need to be done.) > > One can argue that it's too hard to implement them properly, so we ought > to do some subsetting. But if we do that, then we CERTAINLY should leave > the flag the way it is so that if somebody later wants to do it properly, > they at least have the data to do so. Let's say it this way - every simplification to the middle-end helps avoiding (and fixing) obscure bugs in fold-const. For an example, as exercise for the reader try to fix PR33779 which we just produced by looking at the conversion handling from extract_muldiv (which is one "heavy" user of TYPE_IS_SIZETYPE). The condition above the transformation that goes wrong is not exactly easy to understand (nor to fix without essentially disabling all of the transformation): case CONVERT_EXPR: case NON_LVALUE_EXPR: case NOP_EXPR: /* If op0 is an expression ... */ if ((COMPARISON_CLASS_P (op0) || UNARY_CLASS_P (op0) || BINARY_CLASS_P (op0) || VL_EXP_CLASS_P (op0) || EXPRESSION_CLASS_P (op0)) /* ... and is unsigned, and its type is smaller than ctype, then we cannot pass through as widening. */ && ((TYPE_UNSIGNED (TREE_TYPE (op0)) && ! (TREE_CODE (TREE_TYPE (op0)) == INTEGER_TYPE && TYPE_IS_SIZETYPE (TREE_TYPE (op0))) && (GET_MODE_SIZE (TYPE_MODE (ctype)) > GET_MODE_SIZE (TYPE_MODE (TREE_TYPE (op0))))) /* ... or this is a truncation (t is narrower than op0), then we cannot pass through this narrowing. */ || (GET_MODE_SIZE (TYPE_MODE (type)) < GET_MODE_SIZE (TYPE_MODE (TREE_TYPE (op0)))) /* ... or signedness changes for division or modulus, then we cannot pass through this conversion. */ || (code != MULT_EXPR && (TYPE_UNSIGNED (ctype) != TYPE_UNSIGNED (TREE_TYPE (op0)))))) break; /* Pass the constant down and see if we can make a simplification. If we can, replace this expression with the inner simplification for possible later conversion to our or some other type. */ if ((t2 = fold_convert (TREE_TYPE (op0), c)) != 0 && TREE_CODE (t2) == INTEGER_CST && !TREE_OVERFLOW (t2) && (0 != (t1 = extract_muldiv (op0, t2, code, code == MULT_EXPR ? ctype : NULL_TREE, strict_overflow_p)))) return t1; break; Richard.