The function __multi3() is undefined on 32-bit ARM, so a call to it should never be emitted. Instead, plain instructions need to be generated to perform 128-bit multiplications.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
Doesn't this depend on which runtime library you're using? No Arm32 library implement that?
I remember a patch to add 128-bit arithmetic into Armv7 many years ago (from Android) but I'm not sure it ever got into compiler-rt.
Doesn't this depend on which runtime library you're using? No Arm32 library implement that?
I remember a patch to add 128-bit arithmetic into Armv7 many years ago (from Android) but I'm not sure it ever got into compiler-rt.
I got linking errors due to undefined symbol __multi3.
Looking at compiler-rt/lib/builtins/multi3.c, I see that __multi3() is implemented only if CRT_HAS_128BIT is defined:
#ifdef CRT_HAS_128BIT /*...*/ // Returns: a * b COMPILER_RT_ABI ti_int __multi3(ti_int a, ti_int b) { /*...*/
The file compiler-rt/lib/builtins/int_types.h does not define CRT_HAS_128BIT on ARM:
#if defined(__LP64__) || defined(__wasm__) || defined(__mips64) || \ defined(__riscv) || defined(_WIN64) #define CRT_HAS_128BIT #endif
So, I think the answer to your question is no, __multi3() is not implemented for ARM.
Right, ok, this is true for compiler-rt, but not necessarily other runtime libraries.
There is an open discussion if we should assume compiler-rt is the default and use what we have, but this is a different issue.
If the call to __multi3 is there by accident (leaked from other target's default), then it's ok to remove it. If not, we may need some more complex solution.
@compnerd @joerg @t.p.northover @srhines, do you know of any Arm32 runtime library that implements 128-bit maths with Clang?
I think Android does, so perhaps we can add a condition there on AndroidEABI?
We don't define 128-bit operations. https://cs.android.com/search?q=CRT_HAS_128BIT%20-filepath:external%2Fcompiler-rt%20-filepath:external%2Fllvm-project&sq=&ss=android shows that we don't define CRT_HAS_128BIT anywhere, nor do I see any 128-bit symbols in our libclang_rt.builtins-arm-android.a. We do default to compiler-rt these days for builtins, and thus the 128-bit symbols can't be coming from anywhere else either.
We inherited the lack of int128_t support on 32bit platforms from GCC. IMO we should fix that, the only tricky one is division.
We could change compiler-rt to expose the relevant routines if we wanted to. See https://reviews.llvm.org/D43106 etc.
Right, I think it's a bit clearer now.
- We inherited the lack of 128-bit arithmetic from GCC and other targets, so currently, there isn't a default place we can get them from.
- The current version of compiler-rt doesn't have them, nor does libgcc, so if users want them, they have to link their own libs.
- We want to implement them, long term, in compiler-rt, which we also want to make the default in LLVM for all supported targets.
Given the time-frame of item (3) and the fact that, today, the compiler is generating code that doesn't link (without users providing the symbols themselves), I think this change is correct for the time being. I'm creating a bug to address this and adding people here to the CC list.
Otherwise, this patch LGTM, thanks!
@rengolin: I don't have commit access. Can you please commit this patch on my behalf?
Done. I have run tests locally and they were fine, but please look out for buildbot emails to make sure it didn't break anything we didn't test. Thanks!
This breaks tests everywhere as far as I can tell. Eg http://45.33.8.238/linux/48494/step_12.txt
Please take a look and revert for now if it takes a while to fix.
Reverted in 68a1d9a1f5735ec5a595bbe2fffab540b9fc1710 . More or less all bots on https://lab.llvm.org/buildbot/#/console are red.
Thanks Nico! Sorry, I was out for a while. Not sure why I didn't catch this on my build.
@koutheir how did you test this?
@rengolin I tested the ARM tests that I thought would be affected. This appears to be affecting other tests.
I'm currently running a full check-llvm for the ancestor commit of 64e9aa33020d, after which I'll also perform another check-llvm for the commit 64e9aa33020d. If more tests are failing with the commit 64e9aa33020d, then I'll fix them and update the patch.
Right, before submitting a patch, you should run at the very least "ninja check" on the affected components, in your case, LLVM only.
Ok, managed to fix my environment, built and tested fine on x86_64. Let me know if bots crash again.
The commit 789708617d20 caused two failures:
- https://lab.llvm.org/buildbot/#/builders/111/builds/2256
- https://lab.llvm.org/buildbot/#/builders/12/builds/5021
However, I believe these failures are unrelated to these changes. It looks like a problem of selecting the required C++ standard for the LLVM C++ source files.
The build builders/53/builds/3020 fails due a time out. I don't think this is an actual failure. Maybe someone could increase the time out value for certain long-running tests.
You're right, none of these breakages seem related to your patch. Thanks for checking.