support pointer subtraction

[wooster0]

Fixes #1738

I don't know if this should introduce a dedicated AIR instruction instead of emitting two int_from_ptr and a sub_wrap. This is also missing safety just like the existing pointer arithmetic but maybe that can be done as part of #1918? Otherwise, if those two things aren't a blocking issue I think this is more or less complete. It seems to work at least.

I also put an emphasis on introducing a clear distinction between "pointer-integer arithmetic" and "pointer subtraction" (pointer-pointer arithmetic) because both of those are "pointer arithmetic" so "pointer arithmetic" on its own becomes ambiguous.

[wooster0]

A maintainer will have to repush the "update zig1.wasm" commit.

[Vexu]

I don't know if this should introduce a dedicated AIR instruction instead of emitting two int_from_ptr and a sub_wrap

I don't think a dedicated AIR instruction is needed (unless for safety checks in the backend?) but it should do something at comptime since that is mentioned as a reason against just using @intFromPtr in the issue.

[wooster0]

It now works at comptime as well if it knows the byte offset.

[Vexu]

I think it needs to check that the pointers point to the same object for the operation to make sense at comptime. Otherwise it'll have to fall back to doing it at runtime.

[wooster0]

Good point. Could also add some basic "safety" for comptime at least, checking overflow.

[Vexu]

I'm not sure if the problem is Value.ptrField always returning a new field pointer or the base address check being too strict but I'd expect both of these to work:

comptime {
    var a: struct { a: u32, b: u32 } = undefined;
    const p1 = &a.a;
    const p2 = &a.b;
    @compileLog(p2 - p1); // runtime because p1 and p2 have different base addresses
}

comptime {
    var a: [64][64]u8 = undefined;
    const p1 = &a[0][12];
    const p2 = &a[15][3];
    @compileLog(p2 - p1); // comptime because p1 and p2 are offset from the same comptime alloc
}

[wooster0]

Passes now

[Vexu]

But it results in a wrong value since Value.ptrField always sets the byte_offset to 0.

pub fn main() void {
    var a: struct { a: u32, b: u32 } = undefined;
    const p1 = &a.a;
    const p2 = &a.b;
    std.debug.print("{}\n", .{@intFromPtr(p2) - @intFromPtr(p1)}); // 4
}

[wooster0]

Well that's true of course.
Looking closer that's only the case for struct. packed struct and extern struct work. For those it knows the byte_offset.

I considered using structFieldOffset in analyzeArithmetic so that I can get a byte offset for structs too (@offsetOf works on structs) but that doesn't seem possible because you can't get the struct type from the pointer type (it's going to be *u32 without referencing the struct in any way).

The other option would be to change ptrField to use some result of structFieldOffset for byte_offset instead of 0 but it's using 0 for byte_offset in multiple places so there must be some good reason, like the result of structFieldOffset not always being correct because it's an undefined memory layout.

So instead I would only allow packed struct and extern struct at comptime and struct is going to happen at runtime.

[wooster0]

I reverted the hash_map.zig and zig1.wasm changes and kept the logic simple for now. Follow-up issue can be opened.

Result should be object-size units