HomePhabricator

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

Authored by reames on Jun 11 2021, 1:30 PM.

Description

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.

Details

Committed
reamesJun 11 2021, 1:38 PM
Parents
rG22dea6923155: [clang][ObjC] allow the use of NSAttributedString * argument type with format…
Branches
Unknown
Tags
Unknown

Event Timeline

Herald added a subscriber: Restricted Project. · View Herald TranscriptJun 11 2021, 1:40 PM

Is producing a fatal error in the backend an acceptable implementation? The context is that we're trying to use non-integral pointers to model opaque reference types in the WebAssembly backend and a big part of why that was a good modeling was that the verifier would reject inttoptr/prttoint on them.