From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29135 invoked by alias); 30 Jul 2010 16:49:56 -0000 Received: (qmail 29122 invoked by uid 22791); 30 Jul 2010 16:49:56 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Jul 2010 16:49:51 +0000 Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id o6UGnnEI002946 for ; Fri, 30 Jul 2010 09:49:49 -0700 Received: from eydd26 (eydd26.prod.google.com [10.208.30.26]) by kpbe16.cbf.corp.google.com with ESMTP id o6UGnlNg030335 for ; Fri, 30 Jul 2010 09:49:48 -0700 Received: by eydd26 with SMTP id d26so808306eyd.0 for ; Fri, 30 Jul 2010 09:49:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.75.139 with SMTP id y11mr1459515ebj.99.1280508586944; Fri, 30 Jul 2010 09:49:46 -0700 (PDT) Received: by 10.220.42.213 with HTTP; Fri, 30 Jul 2010 09:49:16 -0700 (PDT) In-Reply-To: References: <20100525235926.GA3326@kam.mff.cuni.cz> <20100527075632.GA12991@kam.mff.cuni.cz> <20100528085052.GA3423@kam.mff.cuni.cz> <20100529152243.GA18706@kam.mff.cuni.cz> <20100529191446.GA3996@kam.mff.cuni.cz> <20100604105451.GB5105@kam.mff.cuni.cz> Date: Fri, 30 Jul 2010 16:58:00 -0000 Message-ID: Subject: Re: IVOPT improvement patch From: Xinliang David Li To: "H.J. Lu" Cc: Richard Guenther , Pat Haugen , GCC Patches , Zdenek Dvorak Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true 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: 2010-07/txt/msg02362.txt.bz2 This looks fine to me -- Zdenek or other reviewers --- is this one ok? Thanks, David On Fri, Jul 30, 2010 at 8:45 AM, H.J. Lu wrote: > On Thu, Jul 29, 2010 at 6:04 PM, H.J. Lu wrote: >> It looks strange: >> >> + =A0 =A0 =A0width =3D (GET_MODE_BITSIZE (address_mode) < =A0HOST_BITS_P= ER_WIDE_INT - 1) >> + =A0 =A0 =A0 =A0 =A0? GET_MODE_BITSIZE (address_mode) : HOST_BITS_PER_W= IDE_INT - 1; >> =A0 =A0 =A0 addr =3D gen_rtx_fmt_ee (PLUS, address_mode, reg1, NULL_RTX); >> - =A0 =A0 =A0for (i =3D start; i <=3D 1 << 20; i <<=3D 1) >> + =A0 =A0 =A0for (i =3D 1; i < width; i++) >> =A0 =A0 =A0 =A0{ >> - =A0 =A0 =A0 =A0 XEXP (addr, 1) =3D gen_int_mode (i, address_mode); >> + =A0 =A0 =A0 =A0 =A0HOST_WIDE_INT offset =3D (1ll << i); >> + =A0 =A0 =A0 =A0 XEXP (addr, 1) =3D gen_int_mode (offset, address_mode); >> =A0 =A0 =A0 =A0 =A0if (!memory_address_addr_space_p (mem_mode, addr, as)) >> =A0 =A0 =A0 =A0 =A0 =A0break; >> =A0 =A0 =A0 =A0} >> >> HOST_WIDE_INT may be long or long long. "1ll" isn't always correct. >> I think width can be >=3D 31. Depending on HOST_WIDE_INT, >> >> HOST_WIDE_INT offset =3D -(1ll << i); >> >> may have different values. The whole function looks odd to me. >> >> > > Here is a different approach to check address overflow. > > > -- > H.J. > -- > 2010-07-29 =A0H.J. Lu =A0 > > =A0 =A0 =A0 =A0PR bootstrap/45119 > =A0 =A0 =A0 =A0* tree-ssa-loop-ivopts.c (get_address_cost): Re-apply revi= sion > =A0 =A0 =A0 =A0162652. =A0Check address overflow. >