ziglang/zig

Fork 763

Code Issues 703 Pull requests 285 Activity Actions 29

SPIRV Types Not Considered Equal #35915

New issue

Closed

opened 2026年06月24日 08:40:35 +02:00 by MasonRemaley · 3 comments

MasonRemaley commented

2026年06月24日 08:40:35 +02:00

Owner

Copy link

Zig Version

0.17.0-dev.957+53c670f46

Steps to Reproduce, Observed Behavior, and Expected Behavior

I expected this test to pass:

constSampler=@SpirvType(.sampler);constSampler2=@SpirvType(.sampler);comptimeassert(Sampler==Sampler2);

However, SPIRV types are currently considered to be unique. This issue is partially resolved by #35914, but that fix isn't enough to get the test case passing.

I believe that this is because each type is given a unique name in zirReifySpirvType:

src/Sema.zig

Lines 20603 to 20610 in f26cdb2

constname=tryip.getOrPutStringFmt(

gpa,

io,

pt.tid,

"{f}__SpirvType_{d}",

.{block.type_name_ctx.fmt(ip),@intFromEnum(inst)},

.no_embedded_nulls,

);

If you log the types with @compileLog, you can see the unique names:

@as(type,spirv.Sampler__SpirvType_12)@as(type,spirv.Sampler2__SpirvType_17)

I decided not to PR a fix since it's possible I'm misunderstanding the situation and this is intentional, I haven't dug into the SPIRV backend much yet.

Assuming this isn't desirable, I think we should rework zirReifySpirvType to look more like zirVectorType--ie it should only store its input parameters on the resulting type--and then add some coverage for type equality to test/behavior/spirv.zig.

CC @alichraghi

### Zig Version 0.17.0-dev.957+53c670f46 ### Steps to Reproduce, Observed Behavior, and Expected Behavior I expected this test to pass: ```zig const Sampler = @SpirvType(.sampler); const Sampler2 = @SpirvType(.sampler); comptime assert(Sampler == Sampler2); ``` However, SPIRV types are currently considered to be unique. This issue is partially resolved by #35914, but that fix isn't enough to get the test case passing. I believe that this is because each type is given a unique name in `zirReifySpirvType`: https://codeberg.org/ziglang/zig/src/commit/f26cdb2771a4bb4d5f1d5acc446ec51c3e177f75/src/Sema.zig#L20603-L20610 If you log the types with `@compileLog`, you can see the unique names: ```zig @as(type, spirv.Sampler__SpirvType_12) @as(type, spirv.Sampler2__SpirvType_17) ``` I decided not to PR a fix since it's possible I'm misunderstanding the situation and this is intentional, I haven't dug into the SPIRV backend much yet. Assuming this isn't desirable, I think we should rework `zirReifySpirvType` to look more like `zirVectorType`--ie it should only store its input parameters on the resulting type--and then add some coverage for type equality to `test/behavior/spirv.zig`. CC @alichraghi

MasonRemaley added the

bug

label

2026年06月24日 08:40:35 +02:00

MasonRemaley referenced this issue

2026年06月24日 08:41:21 +02:00

Asserts InternPool keys have unique representations #35914

alichraghi commented

2026年06月24日 12:44:11 +02:00

Member

Copy link

Yes that's intentional. @SpirvType(.runtime_array) types can be decorated via inline assembly so discerning between them was necessary since otherwise this would result a miscompilation:

constArr1=@SpirvType(.{.runtime_array=u32});constArr2=@SpirvType(.{.runtime_array=u32});asmvolatile("OpDecorate %arr ArrayStride 5",[arr]"t"(Arr1));

However, I think you're right because:

My above case reasoning is now irrelevant since types are no longer cached in CodeGen and we have a deduplication ISel which prevents the final module from having two exact types
There are no documented decorations for other types in @SpirvType (sampler/image/sampled_image) and using inline asm to override the default array stride is inherently wrong because we can literally just use a larger or smaller element type instead.

Yes that's intentional. `@SpirvType(.runtime_array)` types can be decorated via inline assembly so discerning between them was necessary since otherwise this would result a miscompilation: ```zig const Arr1 = @SpirvType(.{ .runtime_array = u32 }); const Arr2 = @SpirvType(.{ .runtime_array = u32 }); asm volatile ("OpDecorate %arr ArrayStride 5", [arr] "t" (Arr1)); ``` However, I think you're right because: - My above case reasoning is now irrelevant since types are no longer cached in CodeGen and we have a deduplication ISel which prevents the final module from having two exact types - There are no documented decorations for other types in `@SpirvType` (`sampler`/`image`/`sampled_image`) and using inline asm to override the default array stride is inherently wrong because we can literally just use a larger or smaller element type instead.

👍 1

alexrp added the

arch/spirv

frontend

labels

2026年06月24日 13:23:58 +02:00

mlugg commented

2026年06月24日 13:43:53 +02:00

Owner

Copy link

FWIW, the frontend logic here is incorrect regardless of what the SPIR-V backend needs. Sema cannot blindly return distinct types every time a type-creation instruction is analyzed, because:

Incremental compilation relies on analysis being idempotent for reasonable performance
It makes comptime function call memoization have observable side effects, which the language specification intentionally avoids

If distinct types are necessary, the type still needs to be keyed on something reproducible---for instance the AST node.

(That said, it sounds like you've determined that the distinct types aren't necessary anyway in this case?)

FWIW, the frontend logic here is incorrect regardless of what the SPIR-V backend needs. Sema cannot blindly return distinct types every time a type-creation instruction is analyzed, because: * Incremental compilation relies on analysis being idempotent for reasonable performance * It makes comptime function call memoization have observable side effects, which the language specification intentionally avoids If distinct types are necessary, the type still needs to be keyed on *something* reproducible---for instance the AST node. (That said, it sounds like you've determined that the distinct types aren't necessary anyway in this case?)

alichraghi commented

2026年06月24日 13:48:15 +02:00

Member

Copy link

distinct types aren't necessary anyway in this case?

Correct

> distinct types aren't necessary anyway in this case? Correct

mlugg added this to the Urgent milestone

2026年06月24日 14:17:56 +02:00

alichraghi referenced this issue from a commit

2026年06月30日 10:14:15 +02:00

InternPool: don't store unique info for `@SpirvType`

alichraghi referenced this issue from a pull request that will close it,

2026年06月30日 10:15:21 +02:00

SPIR-V: miscellaneous changes #35974

alichraghi referenced this issue from a commit

2026年06月30日 10:28:44 +02:00

InternPool: don't store unique info for `@SpirvType`

andrewrk closed this issue

2026年07月01日 10:19:30 +02:00

andrewrk modified the milestone from Urgent to 0.17.0

2026年07月01日 10:19:43 +02:00

No Branch/Tag specified

Branches Tags

master

elfv2

spork8

restricted

0.16.x

panic-rewrite

parking-futex-lockfree

windows-Io-cleanup

Io-watch

ParseCommandLineOptions

windows-async-files

poll-ring

debug-file-leaks-differently

debug-file-leaks

ProcessPrng

elfv2-dyn

jobserver

threadtheft

io-threaded-no-queue

0.15.x

Io.net

comptime-allocator

restricted-function-pointers

cli

wasm-linker-writer

wrangle-writer-buffering

sha1-stream

async-await-demo

fixes

0.14.x

ast-node-methods

macos-debug-info

make-vs-configure

fuzz-macos

sans-aro

ArrayList-reserve

incr-bug

llvm-ir-nosanitize-metadata

ci-tarballs

ci-scripts

threadpool

0.12.x

new-pkg-hash

json-diagnostics

more-doctests

rework-comptime-mutation

0.11.x

ci-perf-comment

stage2-async

0.10.x

autofix

0.9.x

aro

hcs

0.8.x

0.7.x

Labels

Clear labels

This proposal is planned.

The web application for interactive documentation and generation of its assets.

backend/c

The C backend outputs C source code.

backend/llvm

The LLVM backend outputs an LLVM bitcode module.

backend/self-hosted

The self-hosted backends produce machine code directly.

binutils

Zig's included binary utilities: zig ar, zig dlltool, zig lib, zig ranlib, zig objcopy, and zig rc.

breaking

Implementing this issue could cause existing code to no longer compile or have different behavior.

build system

The Zig build system - zig build, std.Build, the build runner, and package management.

debug info

docs

An issue with documentation, e.g. the language reference or standard library doc comments.

error message

This issue points out an error message that is unhelpful and should be improved.

frontend

Tokenization, parsing, AstGen, ZonGen, Sema, Legalize, and Liveness.

fuzzing

incremental

Reuse of internal compiler state for faster compilation.

lib/c

This issue relates to Zig's libc implementation and/or vendored libcs.

lib/compiler-rt

This issue relates to Zig's compiler-rt library.

lib/cxx

This issue relates to Zig's vendored libc++ and/or libc++abi.

lib/std

This issue relates to Zig's standard library.

lib/tsan

This issue relates to Zig's vendored libtsan.

lib/ubsan-rt

This issue relates to Zig's ubsan-rt library.

lib/unwind

This issue relates to Zig's vendored libunwind.

linking

Zig's integrated object file and incremental linker.

miscompilation

The compiler reports success but produces semantically incorrect code.

This issue suggests language modifications. If it also has the "accepted" label then it is planned.

release notes

This issue or pull request should be mentioned in the release notes.

testing

This issue is related to testing the compiler, standard library, or other parts of Zig.

zig cc

Zig as a drop-in C-family compiler.

zig fmt

The Zig source code formatter.

zig reduce

The Zig source code reduction tool.

bounty

https://ziglang.org/news/announcing-donor-bounties

bug

Observed behavior contradicts documented or intended behavior.

contributor-friendly

This issue is limited in scope and/or knowledge of project internals.

downstream

An issue with a third-party project that uses this project.

enhancement

Solving this issue will likely involve adding new logic or components to the codebase.

infra

optimization

A task to improve performance and/or resource usage.

question

No questions on the issue tracker; use a community space instead.

regression

Something that used to work in a previous version stopped working

upstream

An issue with a third-party project that this project uses.

use case

Describes a real use case that is difficult or impossible, but does not propose a solution.

No labels

Milestone

Clear milestone

No items

No milestone

0.17.0

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

3 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

ziglang/zig#35915

No description provided.

Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?