Accesses to constant memory are not observable and should be reported as readnone, not readonly. This is consistent with what we do for normal (non-call) instructions: For those, the TBAA metadata will result in pointsToConstantMemory() returning true, which will then result in a NoModRef result, not a Ref result.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This is consistent with what we do for normal (non-call) instructions: For those, the TBAA metadata will result in pointsToConstantMemory() returning true, which will then result in a NoModRef result, not a Ref result.
Okay, I just realized that this statement is not quite true. In fact, we seem to be very inconsistent about how we handle this. When calculating function attributes / FMRB, we ignore constant memory entirely, resulting in NoModRef / readnone. The same is true for the getModRef() API on some instruction kinds, like VAArgInst, CatchPadInst or CatchReturnInst, where we downgrade ModRef to NoModRef.
But then there are other places where we preserve Ref effects on pointsToConstantMemory(). We do this for calls in https://github.com/llvm/llvm-project/blob/98eedd406aa0a9360a8ef3b8bbe85d3d30367fdc/llvm/lib/Analysis/AliasAnalysis.cpp#L257-L260 and for fences in https://github.com/llvm/llvm-project/blob/98eedd406aa0a9360a8ef3b8bbe85d3d30367fdc/llvm/lib/Analysis/AliasAnalysis.cpp#L534-L537.
I believe that the NoModRef / readnone modelling is the correct one, given the current pointsToConstantMemory() semantics of only considering globally constant memory.
Okay, at least for FunctionModRefBehavior / getModRefBehavior() there's a clear answer here: https://github.com/llvm/llvm-project/blob/98eedd406aa0a9360a8ef3b8bbe85d3d30367fdc/llvm/include/llvm/IR/ModRef.h#L60-L62 So at least this patch is correct.
The inconsistent handling in getModRefInfo() is still concerning, though probably it matters little in practice.