[PATCH] D90637: [ValueTracking] Inbounds does not imply nsw
Nuno Lopes via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Nov 3 05:31:43 PST 2020
nlopes added a comment.
In D90637#2369842 <https://reviews.llvm.org/D90637#2369842>, @nikic wrote:
> Hm, I think we need to clarify this in LangRef. We definitely assume this interpretation (unsigned base and signed offset) in some places (e.g. https://github.com/llvm/llvm-project/blob/c938b4a1ed43f3075155e16a7c2792ca8c122258/llvm/lib/Analysis/ScalarEvolution.cpp#L5061-L5072 and I'm pretty sure I've seen it elsewhere as well), but LangRef is really not clear on this point. It's also not completely obvious where the assumption that the pointer address space is unsigned comes from. E.g. on x86-64 the canonical address space is signed (but I don't know about other architectures). We need to clarify whether having an allocated object at `[0xffffffff, 0x00000001]` is legal (signed address space), `[0x7fffffff, 0x80000001]` is legal (unsigned address space) or both.
Agreed. One thing that seems certain (though not mentioned in LangRef) is that a single allocation can only use up to half of the address space. Otherwise can't have positive and negative offsets; we need 1 bit for the sign.
For the issue you mention, we need a little survey of the hardware out there to understand if there's commonality or not (I've no clue).
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D90637/new/
https://reviews.llvm.org/D90637
More information about the llvm-commits
mailing list