[libc] i386 support

[nickdesaulniers]

In order to incorporate llvm-libc into Android, we MUST to support 32b x86.

Currently, the most immediate build failure with -m32 is:

In file included from external/llvm-libc/test/UnitTest/LibcTest.cpp:9:
In file included from external/llvm-libc/test/UnitTest/LibcTest.h:28:
In file included from external/llvm-libc/src/__support/CPP/string.h:14:
In file included from external/llvm-libc/src/string/memory_utils/inline_memcpy.h:22:
external/llvm-libc/src/string/memory_utils/x86_64/inline_memcpy.h:195:22: error: no member named 'K_AVX' in namespace '
llvmlibc::x86'
  195 |   if constexpr (x86::K_AVX) {
      |                 ~~~~~^
external/llvm-libc/src/string/memory_utils/x86_64/inline_memcpy.h:214:17: error: no member named 'Memcpy' in namespace 
'llvmlibc::x86'
  214 |     return x86::Memcpy::repmovsb(dst, src, count);
      |            ~~~~~^
external/llvm-libc/src/string/memory_utils/x86_64/inline_memcpy.h:219:19: error: no member named 'Memcpy' in namespace 
'llvmlibc::x86'
  219 |       return x86::Memcpy::repmovsb(dst, src, count);
      |              ~~~~~^

This is because x86::K_AVX is only defined when LIBC_TARGET_ARCH_IS_X86_64 is, which is 64b only. We probably need more preprocessor guards using LIBC_TARGET_ARCH_IS_X86_64 (64b vs 32b).

(There may be more build or runtime failures)

cc @gchatelet @enh-google

It will be less work for us to support 32b x86 then for Android to drop 32b x86 support.

[llvmbot]

@llvm/issue-subscribers-libc

Author: Nick Desaulniers (paternity leave) (nickdesaulniers)

In order to incorporate llvm-libc into Android, we MUST to support 32b x86.

Currently, the most immediate build failure with -m32 is:

In file included from external/llvm-libc/test/UnitTest/LibcTest.cpp:9:
In file included from external/llvm-libc/test/UnitTest/LibcTest.h:28:
In file included from external/llvm-libc/src/__support/CPP/string.h:14:
In file included from external/llvm-libc/src/string/memory_utils/inline_memcpy.h:22:
external/llvm-libc/src/string/memory_utils/x86_64/inline_memcpy.h:195:22: error: no member named 'K_AVX' in namespace '
llvmlibc::x86'
  195 |   if constexpr (x86::K_AVX) {
      |                 ~~~~~^
external/llvm-libc/src/string/memory_utils/x86_64/inline_memcpy.h:214:17: error: no member named 'Memcpy' in namespace 
'llvmlibc::x86'
  214 |     return x86::Memcpy::repmovsb(dst, src, count);
      |            ~~~~~^
external/llvm-libc/src/string/memory_utils/x86_64/inline_memcpy.h:219:19: error: no member named 'Memcpy' in namespace 
'llvmlibc::x86'
  219 |       return x86::Memcpy::repmovsb(dst, src, count);
      |              ~~~~~^

This is because x86::K_AVX is only defined when LIBC_TARGET_ARCH_IS_X86_64 is, which is 64b only. We probably need more preprocessor guards using LIBC_TARGET_ARCH_IS_X86_64 (64b vs 32b).

(There may be more build or runtime failures)

cc @gchatelet @enh-google

It will be less work for us to support 32b x86 then for Android to drop 32b x86 support.

[enh-google]

In order to incorporate llvm-libc into Android, we MUST to support 32b x86.

is that true? the example you show is a test suite dependency, not an actual libc one...

[gchatelet]

In order to incorporate llvm-libc into Android, we MUST to support 32b x86.

is that true? the example you show is a test suite dependency, not an actual libc one...

The example above is LLVM libc failing to build with -m32. It may seem that the error is coming from LibcTest (which is our equivalent of Google Test) but the failure comes from inline_memcpy.h which is used to implement memcpy. So, yes, LLVM libc is currently not building with -m32. As @nickdesaulniers said though, it's just a macro definition away from working (as far as this error is concerned). I'll prepare a fix.

[gchatelet]

Looking at the remaining places where we have reference to LIBC_TARGET_ARCH_IS_X86_64 instead of LIBC_TARGET_ARCH_IS_X86 (not counting legitimate uses, #93791 and #93790)

% git grep -n LIBC_TARGET_ARCH_IS_X86_64
config/linux/app.h:38:#if defined(LIBC_TARGET_ARCH_IS_X86_64) ||                                     \
src/__support/OSUtil/linux/syscall.h:16:#ifdef LIBC_TARGET_ARCH_IS_X86_64
src/__support/threads/linux/thread.cpp:61:#elif defined(LIBC_TARGET_ARCH_IS_X86_64)
src/__support/threads/linux/thread.cpp:159:#ifdef LIBC_TARGET_ARCH_IS_X86_64
src/__support/threads/linux/thread.cpp:298:#if defined(LIBC_TARGET_ARCH_IS_X86_64)
src/__support/threads/thread.h:43:     defined(LIBC_TARGET_ARCH_IS_X86_64) ||                                    \
src/setjmp/x86_64/longjmp.cpp:12:#if !defined(LIBC_TARGET_ARCH_IS_X86_64)
src/setjmp/x86_64/setjmp.cpp:12:#if !defined(LIBC_TARGET_ARCH_IS_X86_64)
src/threads/linux/Futex.h:17:     defined(LIBC_TARGET_ARCH_IS_X86_64))
test/src/sys/utsname/uname_test.cpp:21:#ifdef LIBC_TARGET_ARCH_IS_X86_64

It seems we have additional work to do around syscall, setjmp, threading, TLSImage (config/linux/app.h).

[nickdesaulniers]

It seems we have additional work to do around syscall,

Indeed, with #93790 applied, the next issue that I encounter is:

In file included from external/llvm-libc/test/UnitTest/TestLogger.cpp:4:
In file included from external/llvm-libc/src/__support/OSUtil/io.h:19:
In file included from external/llvm-libc/src/__support/OSUtil/linux/io.h:13:
external/llvm-libc/src/__support/OSUtil/linux/syscall.h:31:37: error: no matching function for call to 'syscall_impl'
   31 |   return cpp::bit_or_static_cast<R>(syscall_impl(__number, (long)ts...));
      |                                     ^~~~~~~~~~~~
external/llvm-libc/src/__support/OSUtil/linux/io.h:20:19: note: in instantiation of function template specialization 'llvmlibc::syscall_impl<long, int, const char *, unsigned int>' requested here                                       
   20 |   LIBC_NAMESPACE::syscall_impl<long>(SYS_write, 2 /* stderr */, msg.data(),
      |                   ^
external/llvm-libc/src/__support/OSUtil/linux/syscall.h:29:15: note: candidate template ignored: couldn't infer template argument 'R'                                                                                                     
   29 | LIBC_INLINE R syscall_impl(long __number, Ts... ts) {
      |               ^

[nickdesaulniers]

blocker: #110894

[nickdesaulniers]

Going through some of the issues now:

• long double (96b) float to string conversion: [llvm-libc] support for 96b long double (i386) #110894
• startup code
• stack alignment
• fenv_t
• syscall
• signal stack sizes
• jmp_buf
• clone result reg/thread start
• hermetic tests not compiling as 32b

[nickdesaulniers]

I spoke with @lntue today about where I will leave this off.
https://github.com/nickdesaulniers/llvm-project/tree/i386 is the tree+branch where I had this mostly done. It was just the libc.src.math.ddivl and libc.src.math.fdivl smoke tests that were failing. Example:

[ RUN      ] LlvmLibcDivTest.RangeErrors
/android0/llvm-project/libc/test/src/math/smoke/DivTest.h:90: FAILURE
      Expected: __llvm_libc_20_0_0_git::fputil::test_except( static_cast<int>((0x20 | 0x04 | 0x10 | 0x08 | 0x01))) & ((0x10 | 0x20) ? (0x10 | 0x20) : static_cast<int>((0x20 | 0x04 | 0x10 | 0x08 | 0x01)))
      Which is: 0
To be equal to: (0x10 | 0x20)
      Which is: 48

Which looks like it's taking that function and diving "min denormal" by "max normal" then checking for FE_UNDERFLOW | FE_INEXACT. Wasn't sure if it was an issue in my fpe save/restore code or what.