From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39894 invoked by alias); 24 May 2017 08:52:38 -0000 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 Received: (qmail 39870 invoked by uid 89); 24 May 2017 08:52:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=his X-HELO: mail-oi0-f54.google.com Received: from mail-oi0-f54.google.com (HELO mail-oi0-f54.google.com) (209.85.218.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 May 2017 08:52:34 +0000 Received: by mail-oi0-f54.google.com with SMTP id h4so233001344oib.3 for ; Wed, 24 May 2017 01:52:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Tu6Iqbv+1XadeHz7IEsAUFDCjUUSDpvl8DYWhJEY/BE=; b=KkQnJmYvlIEZyRXI4Yr+qkvuh2xerfJVjnNIXmMQyUCfrW67Oa4+dRZxh1JNv+YaVZ Qimeqvzg07sHuA37PW7Jzii8OCOd5Qi26kJTAk+uasRmfKoqvlgQ79g/nlgaM4c1uniJ p9G6lCZQK29LuEXCLWfsawivhcw8ByDkXdkARN97sNIR5PrjkOawK2n/KiE+Q6e8rY3t esjh/ajkvOMN4Fv4Ya7YjYN5f9pVgEzsfZzvaIyMWdC9GwidpYXuv4Pn7HuP7reub/Ak z+XjuzF6R1aO/DoZeOmaJusbc3HgSIF11gBVzckqi77PvubpnQX0WlECz/Lt3ETRj9cZ F+Cg== X-Gm-Message-State: AODbwcAbNVr6Tz/vErzfjuc9EVAl/zZDYqw4w+ngosHo8+IIPy0QRFC8 FV4vUjKR9dRj6QdBwgRc0JLnutzrLA== X-Received: by 10.157.12.67 with SMTP id 61mr4337839otr.237.1495615956628; Wed, 24 May 2017 01:52:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.51.83 with HTTP; Wed, 24 May 2017 01:52:36 -0700 (PDT) In-Reply-To: References: From: Richard Biener Date: Wed, 24 May 2017 08:57:00 -0000 Message-ID: Subject: Re: signed multiplication for pointer offsets To: Marc Glisse Cc: GCC Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg01838.txt.bz2 On Sun, May 21, 2017 at 9:45 PM, Marc Glisse wrote: > Hello, > > when we have a double*p, computing p+n, we multiply n by 8 (size of double) > then add it to p. According to the comment just below the modified lines in > the attached patch, the multiplication is supposed to happen in a signed > type. However, that does not match the current code which uses sizetype. > This is causing missed optimizations, for instance, when comparing p+m and > p+n, we might end up comparing 8*m to 8*n, which is not the same as > comparing m and n if overflow can happen. > > I tried this patch to see how much breaks. And actually, not that much does. > There are a few fragile testcases that want to match "q_. " but it is now > "q_10 ", or they expect 3 simplifications and get 5 (same final code). One > was confused by a cast in the middle of x+cst1+cst2. A couple were hit by > the lack of CSE between (x+1)*8, x*8+8, and some variants with casts in the > middle, but that's already an issue without the patch. A few vectorization > testcases failed because SCEV did not recognize a simple increment of a > variable with NOP casts in the middle, that would be worth fixing. The patch > actually fixed another vectorization testcase. > > I guess it would help if pointer_plus switched to a signed second argument, > to be consistent with this and reduce the number of casts. Yes. In fact the pointer-plus offset is to be interpreted as signed anyway so that it uses unsigned sizetype was a bad decision back in time. Bin tried to fix this last year but I'm not sure what came of his experiments. > I am not proposing the patch as is, but is this the direction we want to > follow, or should I just fix the comment to match what the code does? I think I tried this at some point and I don't remember the result. I did that in the context of the even more ambitious attempt to make pointer-plus take either sizetype or ssizetype typed offsets... The standard doesn't actually talk about what type to perform the multiplication in but given we effectively restrict objects to the size of half of the address space due to ptrdiff_t limitations using either a signed or unsigned type should work. Richard. > -- > Marc Glisse