From patchwork Fri Jul 30 20:43:19 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "H.J. Lu" X-Patchwork-Id: 60382 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id E4D35B6F10 for ; Sat, 31 Jul 2010 06:43:29 +1000 (EST) Received: (qmail 19548 invoked by alias); 30 Jul 2010 20:43:28 -0000 Received: (qmail 19537 invoked by uid 22791); 30 Jul 2010 20:43:27 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mail-vw0-f47.google.com (HELO mail-vw0-f47.google.com) (209.85.212.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Jul 2010 20:43:22 +0000 Received: by vws13 with SMTP id 13so1918887vws.20 for ; Fri, 30 Jul 2010 13:43:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.61.9 with SMTP id r9mr1448592vch.123.1280522599773; Fri, 30 Jul 2010 13:43:19 -0700 (PDT) Received: by 10.220.182.135 with HTTP; Fri, 30 Jul 2010 13:43:19 -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 13:43:19 -0700 Message-ID: Subject: Re: IVOPT improvement patch From: "H.J. Lu" To: Xinliang David Li Cc: Richard Guenther , Pat Haugen , GCC Patches , Zdenek Dvorak X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On Fri, Jul 30, 2010 at 11:46 AM, H.J. Lu wrote: > On Fri, Jul 30, 2010 at 10:54 AM, Xinliang David Li wrote: >> Why is start offset not 1 to begin with? Let's assume it is correct, >> there are a couple of problems in this patch: >> >> 1) when the precision of the HOST_WIDE_INT is the same as the bitsize >> of the address_mode, max_offset = (HOST_WIDE_INT) 1 << width will >> produce a negative number >> 2) last_off should be initialized to 0 to match the original behavior >> 3) The i&& guard will make sure the loop terminates, but the offset >> compuation will be wrong -- i<<1 will first overflows to a negative >> number, then gets truncated to zero,  that means when this happens, >> the last_off will be negative when the loop terminates. >> >> David > > I don't know exactly what get_address_cost is supposed to do. Here is > a new patch which avoids overflow and speeds up finding max/min offsets. > The code is wrong for -m32 on 64bit host. We should start with the maximum and minimum offsets like: width = GET_MODE_BITSIZE (address_mode) - 1; if (width > (HOST_BITS_PER_WIDE_INT - 1)) width = HOST_BITS_PER_WIDE_INT - 1; addr = gen_rtx_fmt_ee (PLUS, address_mode, reg1, NULL_RTX); for (i = width; i; i--) { off = -((HOST_WIDE_INT) 1 << i); XEXP (addr, 1) = gen_int_mode (off, address_mode); if (memory_address_addr_space_p (mem_mode, addr, as)) break; } data->min_offset = off; for (i = width; i; i--) { off = ((HOST_WIDE_INT) 1 << i) - 1; XEXP (addr, 1) = gen_int_mode (off, address_mode); if (memory_address_addr_space_p (mem_mode, addr, as)) break; } data->max_offset = off; Here is the updated patch. H.J. --- > H.J. > --- >> >> On Fri, Jul 30, 2010 at 10:27 AM, H.J. Lu wrote: >>> On Fri, Jul 30, 2010 at 9:58 AM, Xinliang David Li wrote: >>>> There is a problem in this patch -- when i wraps to zero and terminate >>>> the loop, the maxoffset computed will be zero which is wrong. >>>> >>>> My previous patch won't have this problem. >>> >>> Your patch changed the start offset.  Here is the updated patch. >>> >>> >>> H.J. >>>> >>>> David >>>> >>>> On Fri, Jul 30, 2010 at 9:49 AM, Xinliang David Li wrote: >>>>> 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: >>>>>>> >>>>>>> +      width = (GET_MODE_BITSIZE (address_mode) <  HOST_BITS_PER_WIDE_INT - 1) >>>>>>> +          ? GET_MODE_BITSIZE (address_mode) : HOST_BITS_PER_WIDE_INT - 1; >>>>>>>       addr = gen_rtx_fmt_ee (PLUS, address_mode, reg1, NULL_RTX); >>>>>>> -      for (i = start; i <= 1 << 20; i <<= 1) >>>>>>> +      for (i = 1; i < width; i++) >>>>>>>        { >>>>>>> -         XEXP (addr, 1) = gen_int_mode (i, address_mode); >>>>>>> +          HOST_WIDE_INT offset = (1ll << i); >>>>>>> +         XEXP (addr, 1) = gen_int_mode (offset, address_mode); >>>>>>>          if (!memory_address_addr_space_p (mem_mode, addr, as)) >>>>>>>            break; >>>>>>>        } >>>>>>> >>>>>>> HOST_WIDE_INT may be long or long long. "1ll" isn't always correct. >>>>>>> I think width can be >= 31. Depending on HOST_WIDE_INT, >>>>>>> >>>>>>> HOST_WIDE_INT offset = -(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  H.J. Lu   >>>>>> >>>>>>        PR bootstrap/45119 >>>>>>        * tree-ssa-loop-ivopts.c (get_address_cost): Re-apply revision >>>>>>        162652.  Check address overflow. >>>>>> >>>>> >>>> >>> >>> >>> >>> -- >>> H.J. >>> >> > > > > -- > H.J. > diff --git a/gcc/tree-ssa-loop-ivopts.c b/gcc/tree-ssa-loop-ivopts.c index 1d65b4a..b47acc7 100644 --- a/gcc/tree-ssa-loop-ivopts.c +++ b/gcc/tree-ssa-loop-ivopts.c @@ -3241,9 +3241,8 @@ get_address_cost (bool symbol_present, bool var_present, if (!data) { HOST_WIDE_INT i; - HOST_WIDE_INT start = BIGGEST_ALIGNMENT / BITS_PER_UNIT; HOST_WIDE_INT rat, off; - int old_cse_not_expected; + int old_cse_not_expected, width; unsigned sym_p, var_p, off_p, rat_p, add_c; rtx seq, addr, base; rtx reg0, reg1; @@ -3252,33 +3251,38 @@ get_address_cost (bool symbol_present, bool var_present, reg1 = gen_raw_REG (address_mode, LAST_VIRTUAL_REGISTER + 1); + width = GET_MODE_BITSIZE (address_mode) - 1; + if (width > (HOST_BITS_PER_WIDE_INT - 1)) + width = HOST_BITS_PER_WIDE_INT - 1; addr = gen_rtx_fmt_ee (PLUS, address_mode, reg1, NULL_RTX); - for (i = start; i <= 1 << 20; i <<= 1) + + for (i = width; i; i--) { - XEXP (addr, 1) = gen_int_mode (i, address_mode); - if (!memory_address_addr_space_p (mem_mode, addr, as)) + off = -((HOST_WIDE_INT) 1 << i); + XEXP (addr, 1) = gen_int_mode (off, address_mode); + if (memory_address_addr_space_p (mem_mode, addr, as)) break; } - data->max_offset = i == start ? 0 : i >> 1; - off = data->max_offset; + data->min_offset = off; - for (i = start; i <= 1 << 20; i <<= 1) + for (i = width; i; i--) { - XEXP (addr, 1) = gen_int_mode (-i, address_mode); - if (!memory_address_addr_space_p (mem_mode, addr, as)) + off = ((HOST_WIDE_INT) 1 << i) - 1; + XEXP (addr, 1) = gen_int_mode (off, address_mode); + if (memory_address_addr_space_p (mem_mode, addr, as)) break; } - data->min_offset = i == start ? 0 : -(i >> 1); + data->max_offset = off; if (dump_file && (dump_flags & TDF_DETAILS)) { fprintf (dump_file, "get_address_cost:\n"); - fprintf (dump_file, " min offset %s %d\n", + fprintf (dump_file, " min offset %s " HOST_WIDE_INT_PRINT_DEC "\n", GET_MODE_NAME (mem_mode), - (int) data->min_offset); - fprintf (dump_file, " max offset %s %d\n", + data->min_offset); + fprintf (dump_file, " max offset %s " HOST_WIDE_INT_PRINT_DEC "\n", GET_MODE_NAME (mem_mode), - (int) data->max_offset); + data->max_offset); } rat = 1;