[PATCH] D108643: Introduce _BitInt, deprecate _ExtInt

Wed Aug 25 14:00:16 PDT 2021

rjmccall added a comment.

In D108643#2964740 <https://reviews.llvm.org/D108643#2964740>, @aaron.ballman wrote:

> In D108643#2964190 <https://reviews.llvm.org/D108643#2964190>, @rjmccall wrote:
>
>> I agree with James; I know you've reached out to the Itanium ABI group about mangling, but ABI involvement needs to mean also reaching out and getting psABI agreement about representation.  I would suggest proposing a generic ABI, getting consensus on that generic ABI with other implementors, and then running that generic ABI past as many platform ABI groups as you can get in touch with.
>
> I've already reached out to the psABI maintainers and have started those discussions before ever considering the mangling questions: https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/21622785649f2cbacb596d135a417171f52ad539

Okay.  To be clear, that's not "the psABI maintainers", that's specifically the x86_64 psABI group.  Is your expectation that other psABI groups would more or less copy the wording from the x86_64 psABI, potentially replacing 64 with 32 as appropriate, or would you want to host a generic ABI document somewhere else?  If the latter, I think the Clang repository wouldn't be an unreasonable place to do that; we do something similar with blocks.

I would be happy to put you in touch with some other psABI groups when you're ready to talk to them.

> Note that there are some changes expected to that wording (the "bit-aligned" stuff should say "byte-aligned" and we're missing information about bit-fields), so if there are additional changes we'd like to see made, now's a good time to make them.

The choice that high bits are unspecified rather than extended is an interesting one.  Can you speak to that?  That's good for +, -, *, &, |, ^, <<, and narrowing conversions, but bad for ==, <, /, >>, and widening conversions.

One advantage of having a generic ABI is that you can give a rationale in the document, which would be out of scope for a psABI.

>> You can't have bit-fields of `_BitInt` type, can you?  If people want that, or want a truly packed `_BitInt` where `sizeof(_BitInt(56)) == 7`, it's going to add a lot of complexity.
>
> You can have bit-fields of _BitInt type (and we even tell you when you do dumb things with it https://godbolt.org/z/sTKKdb1o1), but I'm not seeing where the complexity comes in from that

What is your expectation of how a `_BitInt` bit-field interacts with adjacent bit-fields?  Does `unsigned a: 1; _BitInt(8) b: 7;` only use 8 bits?  Does `unsigned a: 1; _BitInt(95) b: 95;` only use 96?  Does the latter change based on whether this is a 32-bit or 64-bit target?  Does it change if the type is `_BitInt(128)` instead?  What is the "storage unit" of a `_BitInt` for the purposes of ABIs that are sensitive to such things?

Also, C requires the width of a bit-field to be no larger than the width of the underlying type, but C++ allows "wide" bit-fields, and psABIs are inconsistent about giving rules for their layout.  Does this match that where supported, or is a different set of rules?

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

https://reviews.llvm.org/D108643