LLVM Optimizer emits `mem{cpy,set,mov}`

[antroseco]

(glang) antros@toolbox ~/S/vscode-graphene (master)> glang server.c3 -O3
Error in command: ld.lld --build-id=sha1 --nostdlib --static /tmp/tmppfoqu0vs/tmplbmw_5ew /tmp/tmppfoqu0vs/tmp3ohhx0tt -o a.out
ld.lld: error: undefined symbol: memset
>>> referenced by server.c3:196
>>>               /tmp/tmppfoqu0vs/tmplbmw_5ew:(open_socket(CString))

ld.lld: error: undefined symbol: memcpy
>>> referenced by format.c3:20 (/var/home/antros/Source/GrapheneLang/src/glang/lib/std/format.c3:20)
>>>               /tmp/tmppfoqu0vs/tmplbmw_5ew:(dispatch_rpc_request(RPCRequest, File))

ld.lld: error: undefined symbol: memmove
>>> referenced by vector.c3:38 (/var/home/antros/Source/GrapheneLang/src/glang/lib/std/vector.c3:38)
>>>               /tmp/tmppfoqu0vs/tmplbmw_5ew:(void push_back<JSON_Node>(Vector<JSON_Node>&, JSON_Node))

LLVM correctly deduces what our for loops intend to do in the following scenarios, but unfortunately we don't provide implementations for these functions.

// memset
    for i in range(path:length(), sockaddr.sun_path:length()) {
        sockaddr.sun_path[i] = Narrow<u8>(0x00);
    }

// memcpy
        for index in range(string:length()) {
            buffer.data[index] = string.buffer.data[index];
        }

// memmove
        mut index : isize = 0;
        while index < self.length {
            new_memory.data[index] = self.memory.data[index];
            index += 1;
        }

[antroseco]

Passing --disable-simplify-libcalls to opt seems to work, although I'm a bit sad that we can't use the hyper-optimised architecture-specific versions

[DaveDuck321]

Here's the folder... This looks insane unless we're linking against libc: https://sourceware.org/git/?p=glibc.git;a=tree;f=sysdeps/x86_64/multiarch

Nothing stopping us implenting a pretty good version in the runtime/ standard library tho.

[antroseco]

Here's the folder... This looks insane unless we're linking against libc: sourceware.org/git/?p=glibc.git;a=tree;f=sysdeps/x86_64/multiarch

Nothing stopping us implenting a pretty good version in the runtime/ standard library tho.

Yeah, I saw that too... it's way too much. I wouldn't mind implementing a subset though; but I wouldn't bother too much with SSE/AVX variants