From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8400 invoked by alias); 1 Oct 2007 02:53:36 -0000 Received: (qmail 8392 invoked by uid 22791); 1 Oct 2007 02:53:36 -0000 X-Spam-Check-By: sourceware.org Received: from VLSI1.ULTRA.NYU.EDU (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sourceware.org (qpsmtpd/0.31) with SMTP; Mon, 01 Oct 2007 02:53:34 +0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA21585; Sun, 30 Sep 07 22:57:57 EDT From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10710010257.AA21585@vlsi1.ultra.nyu.edu> Date: Mon, 01 Oct 2007 02:53:00 -0000 To: matz@suse.de Subject: Re: [PATCH] Fix optimization regression in constant folder Cc: ebotcazou@adacore.com, gcc-patches@gcc.gnu.org, iant@google.com, richard.guenther@gmail.com In-Reply-To: References: <200709171539.26653.ebotcazou@adacore.com> <200709301801.39718.ebotcazou@adacore.com> <200710010127.59677.ebotcazou@adacore.com> <10710010056.AA15609@vlsi1.ultra.nyu.edu> 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/msg00007.txt.bz2 > From what Eric and you told us up to now it seems you want this type to > have the following properties: > 1) overflows don't occur (because you make sure that the compiler never > produces overflows on such values) > 2) if overflow were to occur, then it wraps (given the first > property this is weird, but that is what you said) No, that's wrong. As I said, the above is thinking in terms of them as if they were types visible to the user and you are thinking in programming language terms. But they *are not* user-visible types, so I don't think of them in those terms. Sizetypes have always had the the following properties: (1) They can only overflow in a case where the program is clearly illegal: e.g., where the programmer is attempting to construct an object whose size is larger than can be represented by the machine being coded for. (2) Computations on sizetype are "well behaved" in the sense that they do not contain pathalogical cases that require us to supress some optimizations on other integer types. > 3) you want to optimize based on both assumptions, i.e. that overflow > can't occur, and that the type has wrap-around More precisely, you want to do *all* optimizations. For what I'll call "user-visible" types, you may need to restrict certain optimizations to only those types that has some particular flag bits relating to overflow semantics, but for sizetypes, you *always* want to do each of them. > What I think you should want is that the type is simply an unsigned type, > with overflow undefined. (1) sizetype in Ada needs to be signed. (2) if overflow is viewed as undefined, there are optimizations that we would be suppressed but we want to suppress *none* of them. But I don't understand why we need (or want!) to define sizetypes in terms that we'd use for user-visible types: they *aren't* user-visible types, but instead are very special types used for very specific purposes in the compiler. Trying to treat them as if they were user-visible types seems *very* wrong to me, for numerous reasons (among them being tree consistency checking: making sure that the appropriate tree operands are always sizetypes).