[LLVMdev] proposed new rule for getelementptr

[Török Edwin]

On 2009-07-23 00:02, Dan Gohman wrote:
> On Jul 22, 2009, at 1:28 PM, Török Edwin wrote:
>
>
>   
>> On 2009-07-22 21:30, Dan Gohman wrote:
>>
>>     
>>> Hello,
>>>
>>>
>>>
>>> I'm working on refining the definition of getelementptr (GEP) to
>>>
>>> clarify its semantics and to allow front-ends to provide additional
>>>
>>> information to optimization passes.
>>>
>>>
>>>
>>> To help support this, I'd like to propose the following rule:
>>>
>>>
>>>
>>> Any memory access must be done though a pointer value associated
>>>
>>> with with address range of the memory access, otherwise the behavior
>>>
>>> is undefined.
>>>
>>>
>>>
>>>       
>> If I compute an out-of-bounds GEPs and use it in ICMP is that  
>> undefined
>> behaviour, or wrapping behaviour?
>>     
>
> This will be addressed when the wrapping option for GEP is available.
> A wrapping GEP will provide wrapping behavior, and a non-wrapping
> GEP will have an undefined result on overflow. So it's up to the
> front-end to decide which one it wants.
>
>   
>> Instcombine currently does this transform ((gep Ptr, OFFSET) cmp Ptr)
>> ---> (OFFSET cmp 0), which is perfectly
>> fine when GEP is assumed to have undefined behavior on overflow, but  
>> is
>> wrong if GEP is allowed to overflow
>> with well defined behavior (it wraps).
>>
>> Also will can the behavior of GEP be changed depending on llvm-gcc's
>> -fno-strict-aliasing/-fwrapv/-fno-strict-pointer-overflow flags?
>>     
>
> Yes. To implement -fwrapv, the front-end can omit any of the no-overflow
> flags, and choose the wrapping form of GEP, as appropriate.
>
> I'm not familiar with -fno-strict-pointer-overflow. Do you mean
> -fno-strict-overflow? I guess for LLVM that would be equivalent
> to -fwrapv.
>
>   

Yes, I mean -fno-strict-overflow.
Since LLVM has defined semantics for signed overflow, -fwrapv doesn't
add anything wrt. -fno-strict-overflow, yes.

> -fno-strict-aliasing is not impacted.
>   

Will LLVM's default behavior be that of -fstrict-aliasing, or
-fno-strict-aliasing?
We don't have TBAA, but the "computer pointer doesn't alias existing
pointers" sounds like something for -fno-strict-aliasing, no?
I'm not sure what gcc does here, does -fno-strict-aliasing have any
effect on pointer computed from ints?

>   
>>     
>>> Front-ends that do crazy things to pointers may need to use
>>>
>>> ptrtoint+arithmetic+inttoptr instead of getelementptr. If the
>>>
>>> target-independent properties of getelementptr are needed, the
>>>
>>> "getelementptr null" trick may be useful.
>>>
>>>       
>> Will various optimizations make sure they don't introduce undefined
>> operations in programs with otherwise well defined semantics?
>> I think instcombine may turn them into GEPs, thus transforming a  
>> program
>> with well defined semantics according to above rules into
>> undefined semantics. Of course if the optimizer can see that the  
>> access
>> is always well defined it should do this transform.
>>     
>
> Yes. One of the goals of this effort is to legitimize some of what the
> optimizer is already doing, and another is to make some of the things
> it's doing dependent on explicit permission in the form of no-overflow
> flags.
>   

I think this is great. Frontends that want always well-defined behavior
can just set the flags appropriately.

Best regards,
--Edwin