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

[Török Edwin]

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.

Best regards,
--Edwin