[llvm] [GISel][RISCV] Legalize `G_{U|S}DIVREM` (PR #93067)
Craig Topper via llvm-commits
llvm-commits at lists.llvm.org
Wed May 22 20:03:53 PDT 2024
topperc wrote:
> From what I can tell, the primary reason is just because LLVM doesn't know divrem library calls exist [because they've been explicitly set to null](https://github.com/llvm/llvm-project/blob/b91b8fea8c58e9b414e291df677b12ca44197784/llvm/include/llvm/IR/RuntimeLibcalls.def#L73-L82). This is in spite of the fact that [they're defined in compiler-rt](https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/builtins/divmodsi4.c) and should be available. Not only that, but the divrem functions are directly called by div and rem.
>
> The only reasons I can tell for them not to be enabled are to avoid auto-generated 2-output libcalls (which would explain why sincos is also set to null), and because the 128-bit versions aren't built on all targets (which doesn't make as much sense since the 128-bit libcalls for div and rem are unconditionally declared anyways).
>
> [If the libcalls were declared in `RuntimeLibcalls.def`](https://github.com/llvm/llvm-project/pull/68462/files), then LLVM does seem fully capable of generating calls to them in the right circumstances, and even seems to pass the pointer parameter without issue.
There's some other messy issues here. Just a couple example
-libgcc hasn't always exported them and we can't detect in the backend whether we're using compiler-rt or libgcc or the version. Enough time may have passed by now that we can ignore the really old versions of libgcc. And it probably isn't an issue for a newer target like RISC-V.
-32-bit ARM has custom versions in compiler-rt that return 2 registers I think.
I don't think setting them to non-null globally is a good idea. We could set it to non-null in RISCVISelLowering.cpp specifically.
https://github.com/llvm/llvm-project/pull/93067
More information about the llvm-commits
mailing list