[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