bpf __builtin_memcpy from large aligned global spills unnecessarily

[dramforever]

int meow[512 / sizeof(int)];

void cpy(char *dest)
{
        __builtin_memcpy(dest, meow, 512);
}

https://godbolt.org/z/9czYacMfT

Compiles with LLVM 19, Fails with this error on >= 20:

<source>:3:6: error: Looks like the BPF stack limit is exceeded. Please move large on stack variables into BPF per-cpu array map. For non-kernel uses, the stack can be increased using -mllvm -bpf-stack-size.
    3 | void cpy(char *dest)
      |      ^
<source>:3:6: note: could not determine the original source location for example.c:0:0
<source>:3:6: note: could not determine the original source location for example.c:0:0

Reducing the memcpy size to 40 or similar reveals that the code now spills to stack, for seemingly no reason:

cpy:
        r3 = meow ll
        [...]
        w2 = *(u32 *)(r3 + 8)
        *(u64 *)(r10 - 24) = r2
        *(u8 *)(r1 + 8) = w2
        w2 = *(u32 *)(r3 + 4)
        *(u64 *)(r10 - 16) = r2
        *(u8 *)(r1 + 4) = w2
        w3 = *(u32 *)(r3 + 0)
        *(u64 *)(r10 - 8) = r3
        *(u8 *)(r1 + 0) = w3
        [...]

[realqhc]

Perhaps you need to increase bpf stack size per instruction?
https://godbolt.org/z/sca99YWxE

[dramforever]

Perhaps you need to increase bpf stack size per instruction? https://godbolt.org/z/sca99YWxE

@realqhc I cannot do that. My BPF program will be loaded into the kernel and thus cannot override the stack size restriction.

In any case it still doesn't make sense to require a seemingly unbounded amount of stack space for __builtin_memcpy.

I've currently worked around this in hid-bpf-uclogic by making make the source pointer volatile to hide it from optimization. Not ideal, but it fixes the problem for now: dramforever/hid-bpf-uclogic@d9e9438

I can also change the descriptor so that it's a separate "global"/map, but that's annoying from the perspective of the interface between userspace and the BPF program.