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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
