Noalias for dummies

npc1054657282 · January 16, 2026, 3:42pm

I think the design of alias in Zig hasn’t been fully finalized yet, which is why the related keyword lacks documentation.

github.com/ziglang/zig

noalias on all parameters by default (with debug safety); ability to specify mayalias

opened 11:49PM - 13 Jun 18 UTC

andrewrk

breaking proposal research

I'm extracting this (flawed) proposal out of #733. * Add `mayalias` keyword … * Remove `noalias` keyword * `mayalias` valid only on a pointer parameter. It means "may be aliased by global variables or other arguments to this function which are mutable pointers" * Debug safety * At the beginning of each function, verify that no mutable pointers with known sizes (`*T`, `*[N]T`, and `[]T`) overlap with each other, or with any const pointers with known sizes * In Zig IR, pointer values track the set of noalias parameters and global variables possibly referenced * slice and getelementptr instructions that include a noalias var of unknown len ptr in the set do a safety check to find overlap * When generating LLVM, * load instructions based on const ptr noalias variables !alias.scope a scope unique to the function but shared by each other (the function's const ptr alias scope) * load instructions based on mut ptr noalias variables !alias.scope a unique scope per var * Store instructions based on noalias variables !noalias all the function's noalias var scopes they are not based on, and the function's const ptr alias scope * Verify that LLVM can take advantage of these annotations Depends on #561 so we can put llvm parameter attributes on slice pointers This proposal needs work. Consider this example: ```zig const Context = struct { // some useful fields, and then preallocated_point: Point, }; const Point = struct { x: i32, y: i32, } fn incrementXAndPrint(self: *Context, pt: *Point) { pt.x += 1; self.log("point: {v}\n", pt); } test "aoeu" { var c = Context { .preallocated_point = Point { .x = 0, .y = 0 }, }; incrementXAndPrint(&c, &c.preallocated_point); } ``` This would trigger the proposed debug safety but it does not actually represent problematic behavior, since the value is never accessed via the other pointer. One proposal adjustment could be to do all the runtime safety only at store instructions for everything. I fear this would be too slow in practice, however it is worth experimenting with before shutting the idea down. I'll first verify that LLVM would be able to take advantage of these annotations though.

The impact of noalias is reflected in @memcpy and @memmove. The former prohibits overlapping memory copies, allowing for better performance, while the latter allows overlapping memory copies, resulting in worse performance.

Languages like C have rules such as ‘strict aliasing,’ which assume that two pointers of ‘non-compatible types’ do not point to overlapping memory. This is a very controversial feature, and at least Linus does not agree with it.

As far as I know, Zig should also not adhere to strict aliasing rules, but perhaps this means that passing any two pointers, regardless of whether they are of the same type, could potentially be optimized further by specifying noalias.

In addition, when using LLVM’s backend, it still seems to try to make some strict aliasing assumptions, which leads to unexpected results.