IVOPT improvement patch

Xinliang David Li davidxl@google.com
Fri Jul 30 21:13:00 GMT 2010


This final version looks good to me -- and it is more precise.

Thanks,

David

On Fri, Jul 30, 2010 at 1:43 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Jul 30, 2010 at 11:46 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Fri, Jul 30, 2010 at 10:54 AM, Xinliang David Li <davidxl@google.com> 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 <hjl.tools@gmail.com> wrote:
>>>> On Fri, Jul 30, 2010 at 9:58 AM, Xinliang David Li <davidxl@google.com> 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 <davidxl@google.com> 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 <hjl.tools@gmail.com> wrote:
>>>>>>> On Thu, Jul 29, 2010 at 6:04 PM, H.J. Lu <hjl.tools@gmail.com> 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  <hongjiu.lu@intel.com>
>>>>>>>
>>>>>>>        PR bootstrap/45119
>>>>>>>        * tree-ssa-loop-ivopts.c (get_address_cost): Re-apply revision
>>>>>>>        162652.  Check address overflow.
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> H.J.
>>>>
>>>
>>
>>
>>
>> --
>> H.J.
>>
>
>
>
> --
> H.J.
>



More information about the Gcc-patches mailing list