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



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to