@"identifier" syntax accidentally exposes all LLVM intrinsics

[andrewrk]

@shritesh discovered that if you do something like this:

extern fn @"llvm.wasm.memory.size.i32"(u32) u32;
extern fn @"llvm.wasm.memory.grow.i32"(u32, u32) i32;

This actually exposes the underlying LLVM intrinsics. #2286 takes advantage of this to provide the global system allocator for the WebAssembly target.

It's definitely problematic to have this behavior and this bug will get fixed, but we can't just pull the rug out. We need a solution for this use case.

Another use case @shritesh pointed out is the NVPTX target: https://llvm.org/docs/NVPTXUsage.html#reading-ptx-special-registers

In the same way WebAssembly needs these intrinsics, NVPTX needs all the ones in the list linked above.

So far, none of the builtin functions of Zig are target-specific. We could start adding target-specific builtins, or we could take a different approach. The current way to do target-specific instructions is inline assembly. We could teach zig about the (memory.grow) and (memory.shrink) wasm instructions and rely on asm. Zig would detect this pattern and still emit LLVM intrinsics.

[kubkon]

@andrewrk any thoughts on this beyond what's already written up in the issue description? I've actually implemented the two mentioned intrinsics as target-specific builtins (needed for something else) before stumbling upon this issue (yeah, I know...).

I like the idea of having inline (w)asm, but I'm not quite sure how complicated it would be to accommodate instructions such as pushing/popping off the stack intermingled with the Zig code. I could definitely have a look into that though, perhaps initially focusing only on memory.size and memory.grow instructions, anything else generating a hard compile error.

Oh, and just for the record, branch with the intrinsics as target-specific builtins.

[daurnimator]

I think some of the current builtins (like @clz) should also move to whatever mechanism we select here.

[ghost]

My immediate though upon seeing the names is to have a std.llvm module in LLVM builds, that just binds all the intrinsics. So for instance you’d have std.llvm.wasm.memory.size.i32, with no extern in the program itself. It’s the laziest solution, but it covers all current cases without necessarily counting as a bug.