[PATCH] D68342: [Analysis] Don't assume that overflow can't happen in EmitGEPOffset

[Mikhail Maltsev via Phabricator via llvm-commits]

miyuki added a comment.

>> I also thought that "in bounds address of an allocated object" has something to do with the type used in the GEP instruction, but that's not how Clang interprets it.
>>  E.g. for the following code
>> 
>>   int read(int *buf) {
>>     buf -= 2;
>>     return *buf;
>>   }
>>    
>> 
>> It generates the following:
>> 
>>   define dso_local i32 @_Z4readPi(i32* nocapture readonly %buf) local_unnamed_addr #0 {
>>   entry:
>>     %add.ptr = getelementptr inbounds i32, i32* %buf, i64 -2
>>     %0 = load i32, i32* %add.ptr, align 4, !tbaa !2
>>     ret i32 %0
>>   }
> 
> I do not understand this point, could you elaborate please?

Nothing in the code implies that `buf` points to a single i32 value rather than to an element in an array of i32, but Clang nevertheless adds `inbounds`. If InstCombine tried to get an offset from the `getelementptr inbounds i32, i32* %buf, i64 -2` instruction  it would generate a `mul nuw i64 4, -2` instruction, which wraps.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68342/new/

https://reviews.llvm.org/D68342