[PATCH] D117238: [C2x] Add BITINT_MAXWIDTH support

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D117238#3338092 <https://reviews.llvm.org/D117238#3338092>, @erichkeane wrote:

> In D117238#3338071 <https://reviews.llvm.org/D117238#3338071>, @mariospr wrote:
>
>> In D117238#3270125 <https://reviews.llvm.org/D117238#3270125>, @aaron.ballman wrote:
>>
>>> Updated to allow targets to specify the max bitwidth. I was aware that the x86 backend had issues with doing division on larger `_BitInt` objects, but it turns out *all* backends fail to support `_BitInt(129)` or wider division. Because division is a pretty common operation on numeric data types, it seemed to be more user-friendly to specify that we only support 128 bits or less. I tried to make it exceptionally clear that I consider this to be a backend bug though -- we will support wider bit widths in the future once backends have been fixed. These changes make that future path easier to opt into.
>>
>> Hi! I know this question might be very hard to answer but even so I hope you don't mind me trying 😇 ... do you know whether there is any estimation of when `_BitInt(N) / N > 128` will be supported once again in Clang? I'm not an expert at all on this topic (just registered here to comment! 🙂 ) but this hit us in a Chromium-based project which relied on `_BITINT(256)` now that Chromium 100 updated to Clang 15. And while we're already looking into alternative ways of dealing with is (e.g. maybe using Boost's `multiprecision` module), it would be very interesting if we could get a sense (if it's even possible) on how long we could expect the current situation to last.
>>
>> Again, I understand there might not be a clear answer for this at the moment but, since I'm no expert on the matter and I couldn't figure out myself the exact situation by reading this and other tickets in the tracker I thought, I thought I'd ask just in case.
>>
>> Thanks in advance regardless of the answer!
>> Mario
>
> Hi Mario!  Thank you for inquiring!  As you may know, we disabled _BitInt this large since we couldn't handle division/modulus in the code generators.  There is an RFC currently underway (as of today, we have the patches to start supporting this in the backend!) here: https://discourse.llvm.org/t/rfc-add-support-for-division-of-large-bitint-builtins-selectiondag-globalisel-clang/60329
>
> I'm hopeful that the answer here is 'in the near future'.  @mgehre-amd should be able to at least partially revert this patch once the library changes/llvm code generator changes make it in.

I agree with what Erich is saying here. My intention is to increase back to the LLVM maximum again once the IR we generate stops crashing LLVM. However, there's likely to be performance issues with "very large" bit-precise integer types until we've gone through the backend and optimized for those cases (both compile time and runtime performance concerns), so we might want to bump up to something lower than the theoretical max for a while still (though hopefully usefully bigger than 128!).


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

https://reviews.llvm.org/D117238