fhahn added a comment. In D64128#1569836 <https://reviews.llvm.org/D64128#1569836>, @hfinkel wrote:
> In D64128#1569817 <https://reviews.llvm.org/D64128#1569817>, @rjmccall wrote: > > > 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. > > > I don't disagree. But I believe the question is if we have: > > int *x = malloc(4); > int *y = malloc(4); > if (x & ~15 == y) { > *(x & ~15) = 5; // Is this allowed, and if so, must the compiler assume > that it might set the value of *y? > } > If the mask could change the 'relevant' bits of a pointer, like in this example, we would not generate a ptrmask call. We would only generate ptrmask calls here, if the mask only masks out bits that need to be zero due to alignment requirements (and high bits if the pointer size is limited). > Also, and I could be wrong, but my impression is that all of this is extra - > this motivating use case requires generating the intrinsic from the code in > lib/CodeGen/TargetInfo.cpp - generating it from C/C++ expressions is just a > potential additional benefit. Yes, adding it to clang is extra, my main motivation for the intrinsic was to improve performance of tagged pointers used by a different frontend. Generating the intrinsic from C/C++ would just be an additional benefit, to improve handling of tagged pointers and similar code and provide wider testing for the intrinsic. For the LLVM/Clang codebase, most cases we generate ptrmask with this patch come from `PointerIntPair` and those should be fairly easy to handle with a builtin, if we cannot generate it automatically. 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
