"-fno-builtin" and "-fno-builtin-memset" does not affect clang when targeting wasm32

[sikailud]

I am trying to compile to wasm32 and I need to not use the standard library
clang always tries to optimize my loop initialization out into a memset call, and I can't disable it.
Can somebody HELP ME?

[llvmbot]

@llvm/issue-subscribers-backend-webassembly

[sikailud]

by the way:
clang version 16.0.5
Host: x86_64-pc-windows-msvc
Target: wasm32
Thread model: posix

[dschuff]

I don't know of any wasm-specific logic that should affect this so I would be surprised if this was broken just for wasm, but if it is, then we should definitely fix that. Do you happen to have a small reproducer you can share?

[N-R-K]

Indeed, it's not wasm specific. And it's not memset specific either, memcpy and other builtin functions have the same issue.

Here's a simple test case, the only thing that seems to work reliably is gcc's -mstringop-strategy flag (not supported by clang).

[/tmp]~> cat test.c
int main(void)
{
        volatile char buf[1 << 22] = {0}; // volatile to avoid it being optimized out
        return 0;
}
[/tmp]~> clang -ffreestanding -fno-builtin -O2 test.c 
[/tmp]~> objdump -d a.out | grep 'memset'
0000000000401040 <memset@plt>:
  401040:       ff 25 c2 2f 00 00       jmp    *0x2fc2(%rip)        # 404008 <memset@GLIBC_2.2.5>
  401162:       e8 d9 fe ff ff          call   401040 <memset@plt>
[/tmp]~> gcc -ffreestanding -fno-builtin -O2 test.c                         
[/tmp]~> objdump -d a.out | grep 'memset'
0000000000401020 <memset@plt-0x10>:
0000000000401030 <memset@plt>:
  401030:       ff 25 ca 2f 00 00       jmp    *0x2fca(%rip)        # 404000 <memset@GLIBC_2.2.5>
  40105b:       e8 d0 ff ff ff          call   401030 <memset@plt>
[/tmp]~> gcc -ffreestanding -fno-builtin -O2 -mstringop-strategy=loop test.c
[/tmp]~> objdump -d a.out | grep 'memset'

[sikailud]

update: also tested on baremetal x86, doesn't work!

[sikailud]

https://godbolt.org/z/a93cGvEjz
testing on godbolt clang 16
target x86_64 having the same problem.

[BertalanD]

The semantics could be made clearer for this flag, but in my reading, GCC's (which Clang can be assumed to follow) docs imply that -fno-builtin-func only controls whether calls to func() may be replaced with an inline implementation by the compiler:

GCC normally generates special code to handle certain built-in functions more efficiently; for instance, calls to alloca may become single instructions which adjust the stack directly, and calls to memcpy may become inline copy loops. The resulting code is often both smaller and faster, but since the function calls no longer appear as such, you cannot set a breakpoint on those calls, nor can you change the behavior of the functions by linking with a different library. In addition, when a function is recognized as a built-in function, GCC may use information about that function to warn about problems with calls to that function, or to generate more efficient code, even if the resulting code still contains calls to that function. For example, warnings are given with -Wformat for bad calls to printf when printf is built in and strlen is known not to modify global memory.

Furthermore, it says this about the availability of standard library functions with -ffreestanding:

Most of the compiler support routines used by GCC are present in libgcc, but there are a few exceptions. GCC requires the freestanding environment provide memcpy, memmove, memset and memcmp. Finally, if __builtin_trap is used, and the target does not implement the trap pattern, then GCC emits a call to abort.

(https://gcc.gnu.org/onlinedocs/gcc/Standards.html#C-Language)

[AaronBallman]

That's not what -fno-builtin means; that flag means that memset cannot be replaced automatically by an inline implementation. LLVM (and by extension Clang) requires that memset, memcpy, and memmove must be available, even in freestanding mode: https://clang.llvm.org/docs/UsersManual.html#freestanding-builds

https://godbolt.org/z/Pr7rTrja4 shows an example of how that flag works in practice.

Closing the issue as this behavior is by design.