[PATCH] D122090: [PPCISelLowering] Avoid emitting calls to __multi3, __muloti4

[Nick Desaulniers via Phabricator via llvm-commits]

nickdesaulniers added a comment.
Herald added a subscriber: StephenFan.

In D122090#3395207 <https://reviews.llvm.org/D122090#3395207>, @aaronpuchert wrote:

> In D122090#3394964 <https://reviews.llvm.org/D122090#3394964>, @aaronpuchert wrote:
>
>> I was also wondering if we could block the overflow intrinsics only if `Subtarget.getTargetTriple().isGNUEnvironment()` is true, but we can also discuss this separately.
>
> I see that @craig.topper suggested something similar in D109385 <https://reviews.llvm.org/D109385>.
>
> On the Clang side, we have in `clang::driver::ToolChain`:
>
>   enum RuntimeLibType {
>     RLT_CompilerRT,
>     RLT_Libgcc
>   };
>
> and then `virtual RuntimeLibType GetDefaultRuntimeLibType() const`. Going through the overrides (`git grep -A3 GetDefaultRuntimeLibType clang/lib/Driver/ clang/include/clang/Driver/`), it seems that compiler-rt is the default on AIX, BareMetal, Darwin, Fuchsia, Android Linux, OpenBSD, VE, and WebAssembly. But it's just the default, there could still be a `--rtlib=` command line argument. And since the backend is using the builtin even in cases where the original code didn't use it, we have to be very careful.
>
> An alternative is to pass on the `--rtlib=` argument to the backend (or put it into metadata). At least I think the backend currently doesn't know about the runtime library being used.

I think it would only be safe to assume `--rtlib=compiler-rt` if the compiler was driving a full link. Otherwise, the linker could be invoked manually against libgcc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122090