[PATCH] D108643: Introduce _BitInt, deprecate _ExtInt

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Yes, I think it would be fine to fork off a conversation about what the ABI should be; I didn't meant to completely derail this patch.  To be frank, my expectation was that more of this was already settled and documented, so we just needed to add that documentation and clean up a few details.

Stepping back, I have two concerns about the ABI that are deeper than just these open discussions of trade-offs, and which I need to feel comfortable about before I can really sign off on the implementation of this feature from a code-owner perspective.  The first is that I want to make sure we're settling on well-defined ABI rules that aren't just "whatever the corresponding LLVM target happened to do in the summer of 2021 for loads, stores, and arguments of i117 type".   The second is that I want to avoid adding a standard C feature on just a handful of platforms and then washing our hands of it.  The latter is why I am pushing you in the direction of a "lowering" ABI: because it's a generic solution that gives ABI groups the option of simply signing off on with a pair of so-obvious-they-decide-themselves decisions about underlying types, allowing us to rapidly get consensus from a broad spectrum of ABI maintainers because, after all, it's just the ABI they already use for the same general content.  I think that is important because, among other reasons, it is what the C committee has asked you to do as a condition of standardizing this feature.  If ABI groups want to go the extra mile of learning about this specific feature and designing custom ABI rules like "pass large `_BitInt`s by pointer even though literally nothing else in our ABI is passed by pointer", that's their prerogative.  A large number of language features have ABIs specified by lowering, from block pointers (ABI equivalent to a normal object pointer) to C++ member pointers (ABI equivalent to either an integer or a small struct, depending), although the code in TargetInfo doesn't make that explicit (and really it should, because the way it's done now requires a ton of annoying duplication between targets).


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

https://reviews.llvm.org/D108643