large generated code size in `ReleaseSmall`

[dweiller]

Zig Version

0.14.0-dev.2540+f857bf72e

Steps to Reproduce and Observed Behavior

Compile memset from compiler-rt:

zig build-lib -OReleaseSmall -fno-builtin lib/compiler_rt/memset.zig -target x86-64_linux -mcpu znver1

This target generates a 1894 byte memset function whereas -OReleaseFast generates a 209 byte function. The same issue is also present for other cpus as well here is the sample of x86_64 architectures that I checked:

CPU	ReleaseSmall	ReleaseFast
znver1	1894	209
znver2	1894	209
znver3	1894	209
znver4	280	209
znver5	280	209
raptorlake	1838	209
alderlake	1838	209
rocketlake	167	193
tigerlake	167	193
skylake	1894	233

The above table only has rocketlake and tigerlake producing smaller code in ReleaseSmall.

Expected Behavior

ReleaseSmall should generate less code than ReleaseFast (or at the very least be close).

I'm not sure if this is a strictly LLVM problem (and hence needs to be kicked upstream) or if Zig should be telling LLVM to do something a bit differently, but the code sizes for znver{1,2,3} and {raptor,alder,sky}lake looks worrying.

[dweiller]

Note that these results seem very specific to certain code patterns; for example, memcpy ReleaseSmall does produce less code, despite the (Zig) code being very similar in structure.

[RetroDev256]

I hit this bug today - The problem can of course be avoided by setting a target CPU that is not affected. The code size I saw is mostly due to bloat from SIMD. I don't know why the function is being vectorized for ReleaseSmall - It might be the case that LLVM is not receiving the right flags.

In the meantime for those who run into this, you can try dropping this into your root file - It overrides the export from compiler_rt, and it worked for me.

export fn memset(dest: ?[*]u8, c: u8, len: usize) callconv(.C) ?[*]u8 {
    if (len != 0) {
        for (dest.?[0..len]) |*d| d.* = c;
    }
    return dest;
}