[compiler-rt][CMake] Enable TF intrinsics on powerpc32 Linux

[raj.khem]

Summary

clang generates calls to these intrinsics when used for ppc32/linux, when using libgcc this works ok but when using compiler-rt for rtlib it fails with missing intrinsic symbols. also see [1]

[1] https://lists.llvm.org/pipermail/llvm-dev/2014-May/072784.html

[MaskRay]

Note: powerpc64 defines __powerpc__ as well. You need to check whether powerpc64 needs this as well.

[raj.khem]

In D121379#3373679, @MaskRay wrote:

Note: powerpc64 defines __powerpc__ as well. You need to check whether powerpc64 needs this as well.

powerpc64 was covered under __LP64__ define previously, adding __powerpc__ wont change anything for ppc64

[MaskRay]

compiler-rt/lib/builtins/CMakeLists.txt

626

If ppc32 and ppc64 are going to share most files, perhaps rename this variable to powerpc_SOURCES.

[MaskRay]

LGTM.

[glaubitz]

@MaskRay Any chance you could commit this change?

[nikic]

This break the build of compiler-rt with GCC. Even recent GCC fails with "error: unable to emulate 'TI'" for 32-bit powerpc targets. The fact that this even works on Clang seems like a bug, because replacing it with typedef __int128 ti_int results in an __int128 is not supported on this target error in both GCC and Clang.

I think this change is incorrect, and trying to work around a codegen bug. We should not be emitting ti libcalls on 32-bit ppc targets, just like we don't do so for other 32-bit targets like i686 or armv7. I also wasn't able to actually reproduce the emission of such libcalls -- the linked mail (from 2014) refers to shift libcalls, but if I compile this code for powerpc-unknown-linux, I get an expanded instruction sequence (as expected):

typedef _BitInt(128) ti_int;

ti_int test(ti_int x, ti_int y) {
    return x >> y;
}

The only case I found that does emit a libcall is division, but that's an entirely different problem that is being solved by D126644 (it exists for all targets, e.g. 128 bit division will result in a missing __divti3 libcall on i686 as well).

[glaubitz]

@nik

In D121379#3690593, @nikic wrote:

This break the build of compiler-rt with GCC. Even recent GCC fails with "error: unable to emulate 'TI'" for 32-bit powerpc targets. The fact that this even works on Clang seems like a bug, because replacing it with typedef __int128 ti_int results in an __int128 is not supported on this target error in both GCC and Clang.

I guess we should revert this change then?

[nikic]

In D121379#3693118, @glaubitz wrote:

In D121379#3690593, @nikic wrote:

This break the build of compiler-rt with GCC. Even recent GCC fails with "error: unable to emulate 'TI'" for 32-bit powerpc targets. The fact that this even works on Clang seems like a bug, because replacing it with typedef __int128 ti_int results in an __int128 is not supported on this target error in both GCC and Clang.

I guess we should revert this change then?

I think so. I put up a revert patch in D130988.

compiler-rt/lib/builtins/CMakeLists.txt

 
 set(mips_SOURCES ${GENERIC_SOURCES})
 set(mipsel_SOURCES ${mips_SOURCES})
 set(mips64_SOURCES ${GENERIC_TF_SOURCES}
                    ${mips_SOURCES})
 set(mips64el_SOURCES ${GENERIC_TF_SOURCES}
                      ${mips_SOURCES})
 
-set(powerpc_SOURCES ${GENERIC_SOURCES})
-
 set(powerpcspe_SOURCES ${GENERIC_SOURCES})
 
-set(powerpc64_SOURCES
+set(powerpc_SOURCES
   ppc/divtc3.c
   ppc/fixtfdi.c
   ppc/fixunstfdi.c
   ppc/floatditf.c
   ppc/floatunditf.c
   ppc/gcc_qadd.c
   ppc/gcc_qdiv.c
   ppc/gcc_qmul.c
   ppc/gcc_qsub.c
   ppc/multc3.c
   ${GENERIC_SOURCES}
 )
 # These routines require __int128, which isn't supported on AIX.
 if (NOT ${CMAKE_SYSTEM_NAME} MATCHES "AIX")
-  set(powerpc64_SOURCES
+  set(powerpc_SOURCES
     ppc/floattitf.c
     ppc/fixtfti.c
     ppc/fixunstfti.c
-    ${powerpc64_SOURCES}
+    ${powerpc_SOURCES}
   )
 endif()
-set(powerpc64le_SOURCES ${powerpc64_SOURCES})
+set(powerpc64le_SOURCES ${powerpc_SOURCES})
+set(powerpc64_SOURCES ${powerpc_SOURCES})
 
 set(riscv_SOURCES
   riscv/save.S
   riscv/restore.S
   ${GENERIC_SOURCES}
   ${GENERIC_TF_SOURCES}
 )
 set(riscv32_SOURCES
if (CAN_TARGET_${arch})
       filter_builtin_sources(${arch}_SOURCES ${arch})
 
       # Needed for clear_cache on debug mode, due to r7's usage in inline asm.
       # Release mode already sets it via -O2/3, Debug mode doesn't.
       if (${arch} STREQUAL "armhf")
         list(APPEND BUILTIN_CFLAGS_${arch} -fomit-frame-pointer -DCOMPILER_RT_ARMHF_TARGET)
       endif()
 
-      # For RISCV32, we must force enable int128 for compiling long
-      # double routines.
-      if("${arch}" STREQUAL "riscv32")
+      # For some arches, force enable int128 for compiling long double routines.
+      if("${arch}" STREQUAL "powerpc" OR "${arch}" STREQUAL "riscv32")
         list(APPEND BUILTIN_CFLAGS_${arch} -fforce-enable-int128)
       endif()
 
       if(arch STREQUAL "aarch64")
         add_custom_target(
           lse_builtin_symlinks
           BYPRODUCTS ${lse_builtins}
           ${arm64_lse_commands}

compiler-rt/lib/builtins/int_types.h

 #else
     su_int high;
     su_int low;
 #endif // _YUGA_LITTLE_ENDIAN
   } s;
 } udwords;
 
 #if defined(__LP64__) || defined(__wasm__) || defined(__mips64) ||             \
-    defined(__riscv) || defined(_WIN64)
+    defined(__riscv) || defined(_WIN64) || defined(__powerpc__)
 #define CRT_HAS_128BIT
 #endif
 
 // MSVC doesn't have a working 128bit integer type. Users should really compile
 // compiler-rt with clang, but if they happen to be doing a standalone build for
 // asan or something else, disable the 128 bit parts so things sort of work.
 #if defined(_MSC_VER) && !defined(__clang__)
 #undef CRT_HAS_128BIT