-
Notifications
You must be signed in to change notification settings - Fork 11.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integer division of types larger than 128-bits reports a fatal error in the DAG legalizer #44994
Comments
We don't have much support for arbitrary sized integer division, and once we can't legalize to a wider type it does tend to fail - I'm not sure if this is likely to change anytime soon. We don't even handle the likes of:
I may be wrong here but we should be able to legalize (as long as the sign/zero bits are at least half the bitwidth) to:
Alive2 (with smaller types): http://volta.cs.utah.edu:8080/z/FtCZCa
|
Trying to emit general division when we don't have an instruction or libcall is really inconvenient. There is a general algorithm for splitting a divide, but it doesn't map onto SelectionDAG operations easily. And we don't want to ship an arbitrary precision divide implementation in compiler-rt. It would be straightforward to emit a better error message, at least. |
It is unfortunate that we cannot support this division... I believe there is interest from the Rust community in implementing these as well (based on some responses I received to the _ExtInt patch), so it would be nice if we could figure out how to get at least usable code here.
It seems wrong to me (though my LLVM-IR knowledge is limited) that we have IR that passes the versifier that cannot be emitted. Seems to be a violation of the VM-like-model of LLVM. |
If there was really enough demand, we could, I guess, but I don't want to maintain such an implementation. A high-quality division implementation is really complicated.
There's always going to be certain constructs that aren't supported by all targets. Stuff like target-specific intrinsics, exotic floating-point types, exception handling models that only exist on specific targets, etc. We try to avoid this when it's practical, but that isn't always feasible. |
While I agree in concept that there are certain things that aren't supported on all targets, this is 99.9992% of our supported integers, running 2 of the basic 5 operands on it. While a touch cheeky, it seems like it is pretty high visibility (from an IR model, if not necessarily from a consuming language perspective). That said, I suspect we'll get a number of similar issues filed (where LLVM poorly handles integers >128 bits) now that it is exposed in a consuming language. |
My two cents: I think it would suffice to provide a low-quality division implementation -- just something simple so that people could compile expressions like FWIW, I think here is a correct implementation of "divmod" for power-of-two-sized unsigned integers: https://github.com/Quuxplusone/WideIntProofOfConcept |
Hi all, I encountered this bug when writing a JIT for Ethereum VM which has 256-bit integers. So here is a low quality but correct implementation of such a divmod algorithm:
|
mentioned in issue llvm/llvm-bugzilla-archive#46337 |
This issue happens in all backends, btw, and is causing us to specify |
We are considering to built an extra library in compiler-rt to to ship arbitrary precision division and others, called libclang_rt.bitint (or similar). We didn't want to make it part of compiler-rt's builtins library, so it would also work when linking against libgcc instead. |
That seems like a reasonable approach to me. |
We have made an implementation of this with a new library in compiler-rt, a little change to the clang driver to unconditionally link this library and the changes in SelectionDAG to properly call the new functions. The prototypes are like
and it's using Knuth's Algorithm (adapted from llvm/ADT/APInt.h). |
Adds a pass ExpandLargeDivRem to expand div/rem instructions with more than 128 bits into a loop computing that value. As discussed on https://reviews.llvm.org/D120327, this approach has the advantage that it is independent of the runtime library. This also helps the clang driver, which otherwise would need to understand enough about the runtime library to know whether to allow _BitInts with more than 128 bits. Targets are still free to disable this pass and instead provide a faster implementation in a runtime library. Fixes #44994 Differential Revision: https://reviews.llvm.org/D126644
Extended Description
https://godbolt.org/z/nCa-4f
The text was updated successfully, but these errors were encountered: