[PATCH] D64128: [CodeGen] Generate llvm.ptrmask instead of inttoptr(and(ptrtoint, C)) if possible.

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

The pointer/integer conversion is "implementation-defined", but it's not totally unconstrained.  C notes that "The mapping functions for converting a pointer to an integer or an integer to a pointer are intended to be consistent with the addressing structure of the execution environment.", and we do have to honor that.  The standard allows that "the result ... might not point to an entity of the referenced type", but when in fact it's guaranteed to do so (i.e. it's not just a coincidental result of an implementation decision like the exact address of a global variable — no "guessing"), I do think we have an obligation to make it work.  And on a practical level, there has to be *some* way of playing clever address tricks in the language in order to implement things like allocators and so forth.  So this makes me very antsy.

If the general language rules are too permissive for some interesting optimization, it's fine to consider builtins that impose stronger restrictions on their use.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64128