From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22022 invoked by alias); 29 May 2014 17:09:30 -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 22005 invoked by uid 89); 29 May 2014 17:09:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oa0-f45.google.com Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com) (209.85.219.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 29 May 2014 17:09:26 +0000 Received: by mail-oa0-f45.google.com with SMTP id l6so648178oag.18 for ; Thu, 29 May 2014 10:09:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.57.164 with SMTP id j4mr10246081oeq.24.1401383364805; Thu, 29 May 2014 10:09:24 -0700 (PDT) Received: by 10.76.151.198 with HTTP; Thu, 29 May 2014 10:09:24 -0700 (PDT) In-Reply-To: References: <4E18C5BE.6020809@gnu.org> <4E1AD86A.8000800@gnu.org> <4E1DC42D.1010307@gnu.org> Date: Thu, 29 May 2014 17:09:00 -0000 Message-ID: Subject: Re: PING: PATCH [4/n]: Prepare x32: Permute the conversion and addition if one operand is a constant From: "H.J. Lu" To: Andrew Pinski Cc: Paolo Bonzini , GCC Patches Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg02557.txt.bz2 On Thu, May 29, 2014 at 9:23 AM, wrote: > > >> On May 29, 2014, at 9:13 AM, "H.J. Lu" wrote: >> >>> On Wed, May 28, 2014 at 9:52 PM, Andrew Pinski wrot= e: >>>> On Wed, Jul 13, 2011 at 9:39 AM, H.J. Lu wrote: >>>>> On Wed, Jul 13, 2011 at 9:13 AM, Paolo Bonzini wrot= e: >>>>>> On 07/11/2011 05:54 PM, H.J. Lu wrote: >>>>>> >>>>>> The key is the >>>>>>> >>>>>>> XEXP (x, 1) =3D=3D convert_memory_address_addr_space >>>>>>> (to_mode, XEXP (x, 1), as) >>>>>>> >>>>>>> test. It ensures basically that the constant has 31-bit precision, >>>>>>> because >>>>>>> otherwise the constant would change from e.g. (const_int -0x7ffffff= c) >>>>>>> to >>>>>>> (const_int 0x80000004) when zero-extending it from SImode to DImode. >>>>>>> >>>>>>> But I'm not sure it's safe. You have, >>>>>>> >>>>>>> (zero_extend:DI (plus:SI FOO:SI) (const_int Y)) >>>>>>> >>>>>>> and you want to convert it to >>>>>>> >>>>>>> (plus:DI FOO:DI (zero_extend:DI (const_int Y))) >>>>>>> >>>>>>> (where the zero_extend is folded). Ignore that FOO is a SYMBOL_REF >>>>>>> (this >>>>>>> piece of code does not assume anything about its shape); if FOO =3D= =3D >>>>>>> 0xfffffffc and Y =3D 8, the result will be respectively 0x4 (valid)= and >>>>>>> 0x100000004 (invalid). >>>>>> >>>>>> This example contradicts what you said above "It ensures basically t= hat >>>>>> the >>>>>> constant has 31-bit precision". >>>>> >>>>> Why? Certainly Y =3D 8 has 31-bit (or less) precision. So it has th= e same >>>>> representation in SImode and DImode, and the test above on XEXP (x, 1) >>>>> succeeds. >>>> >>>> And then we permute conversion and addition, which leads to the issue = you >>>> raised above. In another word, the current code permutes conversion >>>> and addition. >>>> It leads to different values in case of symbol (0xfffffffc) + 8. >>>> Basically the current >>>> test for 31-bit (or less) precision is bogus. The real question is >>>> for a address >>>> computation, A + B, if address wrap-around is supported in >>>> convert_memory_address_addr_space. >>> >>> Unless the code has already reassociated the additions already. >>> Like in the AARCH64 ILP32 case: >>> >>> (plus:SI (plus:SI (mult:SI (reg/v:SI 80 [ b ]) >>> (const_int -4 [0xfffffffffffffffc])) >>> (subreg/s/u:SI (reg/v/f:DI 79 [ a ]) 0)) >>> (const_int -1073742592 [0xffffffffbffffd00])) >>> >>> The Tree level is correct in that it did not reassociate the addition >>> but the RTL level ignores that. >>> >>> So this patch is invalid and incorrect unless you know the non >>> constant part of the addition is a pointer (which is not the case >>> here). >> >> There is an address overflow. Is the address overflow behavior >> defined here? > > There was no address overflow in the original code and there was no addre= ss overflow in the tree level. The rtl level does introduce an address over= flow but the semantics of plus is defined to be wrapping so there is no ove= rflow. This is blocking me from testing ilp32 under gnu/Linux as ld.so ge= ts miscompiled and stack addresses have the "sign" bit set. > What is your Pmode? --=20 H.J.