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

Tue Jul 9 10:09:21 PDT 2019

fhahn added a comment.

In D64128#1572504 <https://reviews.llvm.org/D64128#1572504>, @rjmccall wrote:

> I would be opposed to any addition of a `-f` flag for this absent any evidence that it's valuable for some actual C code; this patch appears to be purely speculative.  I certainly don't think we should be adding it default-on.  Your argument about alignment is what I was referring to when I mentioned that this is enforcing alignment restrictions in places we traditionally and intentionally haven't.
>
> Note that it won't help Clang's major uses of `PointerIntPair` and `PointerUnion` because our traits say that types like `Decl` and `Type` have more alignment bits than their formal alignment would indicate, and `PointerIntPair` occupies alignment bits starting with the most significant.

In total with this patch, we generate ~180 ptrmask calls when building llvm/clang. As mentioned above, we miss out a bunch of cases, because of `PointerIntPair` putting its data into the most significant bits. I guess we could cover those cases with a builtin and the main motivation for this patch mostly goes away. Do we have any policies against using clang-only builtins in the codebase?

Anyways, thanks for all the feedback and discussion, it was really helpful!

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64128