[llvm-commits] [llvm] r76245 - in /llvm/trunk: include/llvm/Instructions.h include/llvm/Operator.h lib/VMCore/Instructions.cpp

[Dan Gohman]

On Jul 22, 2009, at 3:25 AM, Török Edwin wrote:


> On 2009-07-22 03:12, Dan Gohman wrote:
>
>> On Jul 18, 2009, at 12:37 AM, Duncan Sands wrote:
>>
>>
>>
>>
>>
>>
>>
>>> Hi Dan,
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> +  /// hasNoPointerOverflow - Return true if this GetElementPtr is
>>>>
>>>> known to
>>>>
>>>>
>>>>
>>>> +  /// never have overflow in the pointer addition portions of its
>>>>
>>>> effective
>>>>
>>>>
>>>>
>>>> +  /// computation. GetElementPtr computation involves several
>>>>
>>>> phases;
>>>>
>>>>
>>>>
>>>> +  /// overflow can be considered to occur in index typecasting,
>>>>
>>>> array index
>>>>
>>>>
>>>>
>>>> +  /// scaling, and the addition of the base pointer with offsets.
>>>>
>>>> This flag
>>>>
>>>>
>>>>
>>>> +  /// only applies to the last of these. The operands are added to
>>>>
>>>> the base
>>>>
>>>>
>>>>
>>>> +  /// pointer one at a time from left to right. This function
>>>>
>>>> returns false
>>>>
>>>>
>>>>
>>>> +  /// if any of these additions results in an address value which
>>>>
>>>> is not
>>>>
>>>>
>>>>
>>>> +  /// known to be within the allocated address space that the base
>>>>
>>>> pointer
>>>>
>>>>
>>>>
>>>> +  /// points into, or within one element (of the original
>>>>
>>>> allocation) past
>>>>
>>>>
>>>>
>>>> +  /// the end.
>>>>
>>>>
>>>>
>>>>
>>>>
>>> can you please add something explaining that for GEP's for which
>>>
>>> overflow results in undefined behaviour (currently always the case),
>>>
>>> hasNoPointerOverflow returns true because the undefinedness means
>>>
>>> that you are allowed to pretend it never overflows, even if it does.
>>>
>>> At least, I suppose that's why you set this to return true always!
>>>
>>>
>>>
>>
>>
>> Hi Duncan,
>>
>>
>>
>> I've backed out this flag for now. Finding the right semantics for
>>
>> an overflow flag for GEP has been complicated; I plan to
>>
>> re-introduce such a flag once I have the semantics for GEP
>>
>> defined in a way that permit it to be useful.
>>
>>
>>
>>
>>
>
> Hi Dan,
>
> How about a flag that tells you that the pointer GEP computed is  
> always
> pointing to valid memory? Then by definition it didn't wrap.
> Then optimizers would know that they can dereference the pointer at
> anytime, even speculatively executing some loads (unless they are  
> volatile).
>
> And by always valid I mean provably always valid: it is never null, it
> is not allocated but freed memory, and it is not the result of  
> undefined
> behavior.

A single bit is insufficient for such information. The property of being
safe for speculative loads is commonly dependent on control flow, for
example:

   if (c)
     for (i=0;i<N;++i)
       if (d)
         y += x[i];

Here, it may be determined that &x[i] is always within the loop,
and could perhaps be speculated ahead of the (d) check, but it
may not be safe to speculate ahead of the (c) check. This is a little
obscure, but it could potentially arise if the loop is unrolled.
With a single bit, there's no way to specify which conditions past
which a load may be safely speculated.

In any case, speculating loads profitably is not a problem I'm looking
to tackle :-).

Dan