[llvm-dev] Question about Alias Analysis with restrict keyword

Friedman, Eli via llvm-dev llvm-dev at lists.llvm.org
Mon Jun 18 15:17:05 PDT 2018

On 6/18/2018 8:16 AM, jingu at codeplay.com wrote:
> On BasicAAResult::aliasGEP()
> 1297     // Check to see if these two pointers are related by the 
> getelementptr
> 1298     // instruction.  If one pointer is a GEP with a non-zero 
> index of the other
> 1299     // pointer, we know they cannot alias.
> 1300
> 1301     // If both accesses are unknown size, we can't do anything 
> useful here.
> 1302     if (V1Size == MemoryLocation::UnknownSize &&
> 1303         V2Size == MemoryLocation::UnknownSize)
> 1304       return MayAlias;

The check for UnknownSize is here because it's impossible to 
disambiguate the offsets of two pointers which both have unknown size, 
so the rest of BasicAAResult::aliasGEP can't do anything useful.

> 1305
> 1306     AliasResult R = aliasCheck(UnderlyingV1, 
> MemoryLocation::UnknownSize,
> 1307                                AAMDNodes(), V2, 
> MemoryLocation::UnknownSize,
> 1308                                V2AAInfo, nullptr, UnderlyingV2);
> On line 1306, we can see the V1Size and V2Size are set up with 
> "MemoryLocation::UnknownSize" and it causes may-alias. On line 1302 
> and 1033, there are checking code for "MemoryLocation::UnknownSize"... 
> I am not sure whether it is bug or not... Can someone let me know why 
> it passes "MemoryLocation::UnknownSize" please? If I missed something, 
> please let me know.

UnderlyingV1 is the base of the GEP.  So this is asking whether the base 
of the GEP aliases V2.  It uses UnknownSize because the offset is 
unknown; it can't tell which bytes are accessed, so it's using an 
approximation instead.

We could theoretically try to be a bit more clever here if the size is 
known and the GEP offset is constant: we could instead pass 
V1Size+GEP1BaseOffset.  Not sure that would have much effect in 
practice, though.


Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

More information about the llvm-dev mailing list