over-eager dead-code-elimination when using @export in initializer

[Sivecano]

Zig Version

0.14.1

Steps to Reproduce and Observed Behavior

I've found that when declaring a private variable with a comptime function, DCE can be over-eager leading to it discarding wanted side-effects.

example:

fn versioned(T: type) *T {
    const vt = packed struct {
        value: T = undefined,
        version: i32,
    };

    const ns = struct{
        pub var wrapper: vt = .{.version = 1};
    };

    @export(&ns.wrapper, .{.name = "hello"});

    return &ns.wrapper.value;
}

const veri = versioned(i32);

will not actually export a symbol called "hello" since the compiler will erroneously optimize away the variable veri.
if we prevert veri from geting optimized away (by using it in on-dead code, exporting it in an api or similar), then
the symbol appears in the shared object file.

compiled using zig build-lib -dynamic

using code above:
nm -DW outputs

                 U __tls_get_addr
                 U getauxval

after adding

export fn a() void {
    veri.* = 5;
}

to the above

nm -DW outputs

                 U __tls_get_addr
00000000000e0870 T a
                 U getauxval
0000000000107118 D hello

this was tested on linux only.

Expected Behavior

don't optimize away code that has influence on compiler state.

[alexrp]

This seems like expected behavior. It would undermine lazy analysis if we had to scan the full call graph to look for things like @export.

[Sivecano]

but it breaks semantics, no?

also this code here

fn vT(T: type) type {
    return packed struct {
        value: T = undefined,
        version: i32,
    };
}

fn versioned(T: type) *T {
    const vt = vT(T);
    const ns = struct {
        pub var wrapper: vt = .{ .version = 1 };
    };

    // @export(&ns.wrapper, .{ .name = "hello" });

    return &ns.wrapper.value;
}

const veri = versioned(i32);

comptime {
    @export(@as(*vT(i32), @alignCast(@fieldParentPtr("value", veri))), .{ .name = "hello" });
}

does export "hello" correctly.

I mean it's clear why, since now veri is no longer dead (at least at comptime)
but shouldn't the runtime properties of the this and the first example be expected to be the same?

[Sivecano]

*excuse if I am a bit clumsy in my communication, I do not mean to come across as combative.

[alexrp]

No, I don't think so. Think about it: If this was the case, we'd have to eagerly analyze literally anything and everything in a Zig program because it could lead to an @export.

[Sivecano]

but from a programmer's POV this code is alive, I mean this is a top-level declaration.
Though I suppose, the same could be said about unused functions.

Maybe there should just be a warning in the documentation about cases like these.

The thing that makes me a bit uncomfortable here is that it requires the programmer to suddenly consider
compiler behaviour like its DCE policy with the only (direct) fix being some sort of hack like

comptime {
    _ = veri; // avoid DCE of verti
}

this does not feel very zig zen to me.

[pfgithub]

Zig in its standard library has declarations like this:

zig/lib/std/zig.zig

Line 20 in 80170d0

pub const CrossTarget = @compileError("deprecated; use std.Target.Query");

If every declaration was analyzed, it wouldn't compile. Nothing is analyzed unless it is referenced by analyzed code.

[alexrp]

The thing that makes me a bit uncomfortable here is that it requires the programmer to suddenly consider
compiler behaviour like its DCE policy

To be clear, it isn't just compiler behavior - it's part of the language semantics. Any Zig implementation must work this way. The language reference could maybe do a better job spelling that out. I think a lot of us just take that for granted.