D80465 added an assembly implementation of muldi3 for RISC-V but it didn't add it to the cmake *_SOURCES list, so the C implementation was being used instead. This patch fixes that.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I haven't had time to try building compiler-rt with this fix, however there is nowhere else in the build system that riscv/muldi3.S is referenced, so I'm happy to accept this patch as improving compiler-rt.
compiler-rt/lib/builtins/CMakeLists.txt | ||
---|---|---|
574 | Is it intentional that mulsi3.S is up here but muldi3.S is in a separate 64-bit block below? |
compiler-rt/lib/builtins/CMakeLists.txt | ||
---|---|---|
574 | Yes. for riscv32 we use the generic muldi3 (which will internally rely on mulsi3), while for riscv64 we only need muldi3, so I think they never need to be included at the same time, and thus they appear in these separate blocks. (Please let me know if you/anyone thinks I'm wrong about this.) |
I meant muldi3.S and mulsi3.S, not the .inc file - I don't think either is changed by that patch yet?
Yes, those #ifs remain. Honestly I don't see much point in them though, the way they are currently written. Including riscv\mulsi3.S in the CMake config should already imply the correct thing (otherwise it's super misleading at best), so the #if shouldn't really be required. Perhaps they would make more sense in terms of a #if !... #error ... #endif flow to guard against unexpected conditions.
Is it intentional that mulsi3.S is up here but muldi3.S is in a separate 64-bit block below?