Post #2290664

2026-05-08 05:31 UTC

@gfxstrand@social.treehouse.systems "In general, the approach is to always assume two derefs may alias and try to prove otherwise. If the proof fails, we have to assume the worst." :'( it was somewhat surprising to me how conservative nir / shader frontends are on this front, given that spir-v gives carte blanche to assume memory declarations don't alias unless they're explicitly marked with Aliased (as long as you're not in OpenCL mode anyway).

Replies (1)

@gfxstrand@social.treehouse.systems 2026-05-08 05:51

@dotstdy@mastodon.social Yes and no. Yes, that’s what the spec appears to say but it’s deceptive. The problem is that you can’t really reason about aliasing from a positive direction like that. If it’s just variables, sure, that’s fine. But you can have aliasing pointers even without aliasing variables. For example, s.a[0] and s.a[i] may alias and that’s just with one variable. So when we’re trying to reason about this inside the compiler, we have to be super careful. First, we chase the dereference chains back as far as we can. If we can chase both back to variables and those variables don’t alias, then we’re good. If they might alias, then we’re toast. If we can chase both dereferences back to a common ancestor, then we play the game of trying to prove they don’t point to overlapping ranges in the variable. If we can’t chase one or both of them back to a variable and we can’t find a common ancestor then, again, we have to assume the worst. The “you can assume no aliasing” only really helps with the first case. The rest is all up to the compiler to figure out. IMO, the way we specified this stuff in SPIR-V was a mistake. Same goes with having a NonUniform decoration instead of a Uniform hint. They made sense in the context of GLSL but don’t generalize well. We (SPIR-V spec folks) are working on digging our way out of both of those holes but it’s hard now that the wrong precedent has been set.

Open ##2290665