[DirectX] Disable all libcalls for DXIL in TargetLibraryInfo.cpp

[Icohedron]

Fixes #138787

To the best of my knowledge, DXIL does not (and should not) support any of the libcalls in TargetLibraryInfo.def.
Math libcalls are not used in HLSL and also do not have lowerings to DXIL. (The current implementation of math functions are done via intrinsics.)
If there is a mistake with disabling all libcalls, then the libcalls we need can be re-enabled in a follow-up PR.

Locally, the codegen tests for Clang HLSL and the DirectX backend appear to pass without any issues.
The offload test suite's clang-d3d12 tests are also passing locally (Unsupported: 31 (62.00%), Passed: 19 (38.00%))
The change this PR introduces also eliminates the problematic memcpy intrinsics operating with a non-constant length argument and addrspace(3) ptrs showing up when compiling DML shaders. The number of DML shaders compiling successfully is greater with this PR than without.

[llvmbot]

@llvm/pr-subscribers-llvm-analysis

Author: Deric C. (Icohedron)

Changes

Fixes #138787

To the best of my knowledge, DXIL does not (and should not) support any of the libcalls in TargetLibraryInfo.def.
Math libcalls are not used in HLSL and also do not have lowerings to DXIL. (The current implementation of math functions are done via intrinsics.)
If there is a mistake with disabling all libcalls, then the libcalls we need can be re-enabled in a follow-up PR.

Locally, the codegen tests for Clang HLSL and the DirectX backend appear to pass without any issues.
The offload test suite's clang-d3d12 tests are also passing locally.
The change this PR introduces also eliminates the problematic memcpy intrinsics operating with a non-constant length argument and addrspace(3) ptrs showing up when compiling DML shaders. The number of DML shaders compiling successfully is greater with this PR.

---

Full diff: https://github.com/llvm/llvm-project/pull/138991.diff

1 Files Affected:

• (modified) llvm/lib/Analysis/TargetLibraryInfo.cpp (+5)

diff --git a/llvm/lib/Analysis/TargetLibraryInfo.cpp b/llvm/lib/Analysis/TargetLibraryInfo.cpp
index 3945dd4a8b55d..1934fb4e1fa26 100644
--- a/llvm/lib/Analysis/TargetLibraryInfo.cpp
+++ b/llvm/lib/Analysis/TargetLibraryInfo.cpp
@@ -205,6 +205,11 @@ static void initializeLibCalls(TargetLibraryInfoImpl &TLI, const Triple &T,
     return;
   }
 
+  if (T.isDXIL()) {
+    TLI.disableAllFunctions();
+    return;
+  }
+
   // memset_pattern{4,8,16} is only available on iOS 3.0 and Mac OS X 10.5 and
   // later. All versions of watchOS support it.
   if (T.isMacOSX()) {

[farzonl]

To the best of my knowledge, DXIL does not (and should not) support any of the libcalls

This is correct we do not support libcalls

If there is a mistake with disabling all libcalls, then the libcalls we need can be re-enabled in a follow-up PR.

We should not enable any libcalls if something breaks thats probably a bug. If say we some how ended up in SimplifyLibCalls.cpp replaceUnaryCall that replaces libcalls with intrinsics that would still be wrong we shouldn't have ended up as a libcall to begin with.

The change this PR introduces also eliminates the problematic memcpy intrinsics

This seems to be more a side effect of how a few optimizations have been written than a defintitive stop all memcpys for example llvm/lib/Transforms/Scalar/MemCpyOptimizer.cpp says:

   // Don't introduce calls to memcpy/memmove intrinsics out of thin air if
  // the corresponding libcalls are not available.

llvm-project/llvm/lib/Transforms/Scalar/MemCpyOptimizer.cpp

Lines 633 to 639 in eebb50a

	// Don't introduce calls to memcpy/memmove intrinsics out of thin air if
	// the corresponding libcalls are not available.
	// TODO: We should really distinguish between libcall availability and
	// our ability to introduce intrinsics.
	if (T->isAggregateType() &&
	(EnableMemCpyOptWithoutLibcalls ||
	(TLI->has(LibFunc_memcpy) && TLI->has(LibFunc_memmove)))) {

All that said we should still do this change, because we don't want libcalls but I want to emphasize that I don't think this solves the memcpy problem in an intentional way.