[all-commits] [llvm/llvm-project] ac81cb: Allow ptrtoint/inttoptr of non-integral pointer ty...

[Philip Reames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: ac81cb7e6dde9b0890ee1780eae94ab96743569b
      https://github.com/llvm/llvm-project/commit/ac81cb7e6dde9b0890ee1780eae94ab96743569b
  Author: Philip Reames <listmail at philipreames.com>
  Date:   2021-06-11 (Fri, 11 Jun 2021)

  Changed paths:
    M llvm/docs/LangRef.rst
    M llvm/lib/IR/Verifier.cpp
    M llvm/test/Transforms/RewriteStatepointsForGC/base-inttoptr.ll
    M llvm/test/Transforms/RewriteStatepointsForGC/constants.ll
    M llvm/test/Verifier/non-integral-pointers.ll

  Log Message:
  -----------
  Allow ptrtoint/inttoptr of non-integral pointer types in IR

I don't like landing this change, but it's an acknowledgement of a practical reality.  Despite not having well specified semantics for inttoptr and ptrtoint involving non-integral pointer types, they are used in practice.  Here's a quick summary of the current pragmatic reality:
* I happen to know that the main external user of non-integral pointers has effectively disabled the verifier rules.
* RS4GC (the lowering pass for abstract GC machine model which is the key motivation for non-integral pointers), even supports them.  We just have all the tests using an integral pointer space to let the verifier run.
* Certain idioms (such as alignment checks for alignment N, where any relocation is guaranteed to be N byte aligned) are fine in practice.
* As implemented, inttoptr/ptrtoint are CSEd and are not control dependent.  This means that any code which is intending to check a particular bit pattern at site of use must be wrapped in an intrinsic or external function call.

This change allows them in the Verifier, and updates the LangRef to specific them as implementation dependent.  This allows us to acknowledge current reality while still leaving ourselves room to punt on figuring out "good" semantics until the future.