Repository navigation
proposal: eliminate the aliasing restrictions #5611
Description
Activity
In the WGSL discussion on 2026-03-24, Mozilla and Google didn't know whether this removal would impact the WebKit implementation.
The current MSL spec says in 5.2 Function Arguments and Variables
Buffers (device) specified as argument values to a graphics or kernel function cannot alias; that is, a buffer passed as an argument value cannot overlap another buffer passed to a separate arugment of the same graphics or kernel function. (p116)
I see now MikeW's comment here on MSL's aliasing hazards. Paraphrasing,
hazards there require:
two or more parameters referring to the same root variable and at least two are read or written to in the function, creating read-write or write-read hazards
I.e.,
-fno-strict-aliasingis not even needed so as long as there are no read-write or write-read hazardsCombining these rules, my reading is that if all device-pointer arguments are passed into the MSL entry point via a single argument buffer, then there is no hazard.
Reacted by mwyrzykowskiCombining these rules, my reading is that if all device-pointer arguments are passed into the MSL entry point via a single argument buffer, then there is no hazard.
This is my understanding too
This will have an impact on the uniformity analysis. In particular, the function variable value analysis. Uniformity assumes no aliasing when deciding on values a variable might hold. There are a couple reasonable ways forward:
- Add a uniformity error if any parameter that must be uniform is aliased at a function call.
- Add new edges when the Load Rule occurs for function scope variables to join possible aliases.
Our preference is to start with 1.
It is worth noting that both of these approaches could have something akin to TBAA added. That is, only certain types could alias (same or one containing the other).
Reacted by mwyrzykowski and Jim Blandyminutes from WGSL committee meeting 2026-7-14
- JB: This seems urgent, if buffer_view is to be usable.
- JB: Bufferview has CTS and impl
- AB: Was going to check if we're good to land
- JB: Text is approved, just blocked on cts. But, without this can only make one slice from buffer and that just kills it. Felt like we should bump the speed of this issue. The final status of this, AB commented a week ago
- AB: Was looking internally, spec wise biggest change is uniformity analysis which does function variable analysis which assumes no aliasing. To assume aliasing have to tie variable values together or say can't alias something sensitive to uniformity which I think is our preference. Could downgrade that to all edges in the graph in the future. Could start with changing the rules os you just can't do it for uniformity. Still based on uniformity diagnostics, if this is in the error set and aliased then issue a diagnostic.
- JB: Another possibility perhaps we could have operations on buffer views that split it at an offset, giving 2 buffer views which are disjoint. Can statically know it doesn't alias. If user knows order of offset they're using (which side of the split they want) then would like folks chop up the buffer statically.
- AB: Worried talking about 2 things. Uniformity only effects function. Any global is non-uniform and for buffer view, only a problem if first a bunch of views and then pass to a function. There is a usability issue but not that you can't take multiple buffer views.
- JB: Ah, was confused about that. Your preference is option 1 from the issue, issue error if aliased must be uniform at function call
- AB: Have options along the lines of if one of the param is int and the other is float, won't alias in WGSL at function scope. If one is a structure it might alias. Could do type based to tighten it.
- MW: With regards to buffer view don't think removing aliasing restrictions is an issue if you only write to one type of the buffer in any execution and the compiler can prove that. A little different then in one of the issues. In bindless so far , wouldn't be able to reinterpret the same buffer view as multiple types and perform writes from different types from the same buffer.
- JB: To be explicit, mentioned, in the issue, the expected implementation strategy is the same as for unrestricted pointers where we just lower all accesses to index's anyway, so gets around backend restrictions.
- AB: Generally yes. Metal could potentially be different but for SPIR-V and HLSL would extend that to more places. We already do those transforms, would just apply in more places. Would look at the aliasing requirement before doing it everywhere.
- JB: LOoks like Metal could just work.
- JB: That's what I wanted out of this discussion. How much of buffer view it blocks. Not blocking slicing and dicing storage buffers. So, really only the other uses that we need to be concerned about. Probably buffer view is more usable then I expected.
- AB: Aliasing rules will be blocked on Dawn getting to argument buffers. In progress but behind other work.
From the minutes:
JB: To be explicit, mentioned, in the issue, the expected implementation strategy is the same as for unrestricted pointers where we just lower all accesses to index's anyway, so gets around backend restrictions.
Just to confirm: Tint generates multiple copies of callees, specialized to the combination of originating variables of the actual pointer parameters, so that the body knows which globals to access?
RESOLVED: Committee agrees on the feature and behavior; ready for PR. However, this will likely not be addressed soon.
minutes from WGSL committee meeting 2026-8-25
- JB: Implementation is to generate specialized copies of functions based on globals being accessed, the same as unrestricted pointer params, yes?
- JP: Yes
- JB: Asked similar question but didn't get down to brass tacks. Confirmed in discussion that the metal restrictions are fine and the implementation is just for the sake of HLSL and is the same implementation technique we already need for unrestricted pointer parameters. So, really just adding a language extension to WGSL to life the requirements of the aliasing section and adjusts the uniformity analysis as needed. Alan sketches two possibilities and suggests the conservative version. That seems good to me. Marked thumbs up from Mozilla.
- AB: Will take take to get to this as we see it gated on argument buffers which we haven't switch too. We plan to do this but it's not immediate.
- JB: WGPU will do at the same time as unrestricted pointer params so wont' get to immediate. But this is a serious requirement for bufferView usability so we'll all get to it eventually.
- AB: Any bindless really. I think you'd be restricted from that, or maybe we don't care due to the pointers.
- JB: DN said if kept the aliasing restriction will limit bindless and bufferView proposals. So that's why I was thinking we'd have to take something like this. Mozilla agrees we should do it, saw a thumbs up from MW. Next step is a PR.
- AB: Will be a ways off, spec doesn't need much if there is no implementation to backup with.
- JB: RESOLVED: Ready for PR.
@dneto0 Is this comment concerning, for this proposal? #5581 (comment)
It seems to me that, if the MSL program I posted to #5581 is not well-defined, then the extension proposed here would force WGSL pointers to be translated into MSL that passes along the pointer that was presented to the kernel function, along with an index. That is, the proposed extension would prevent us from using MSL references to represent WGSL pointers.
Am I misunderstanding?
Assuming I'm not misunderstanding:
I'm concerned about this, because languages generally declare certain behaviors to be undefined because they want their compilers to be free to apply optimizations that are sound only if such behavior does not occur. While one can certainly get around MSL's restrictions on reference aliasing by not using references, in doing so we are switching from one feature (references) that MSL places constraints on, to another feature (indexing) that MSL does not place constraints on. This means that the compiler cannot make as many assumptions about the code, which may mean that it cannot optimize it as well.
For example, aliasing analysis may help determine whether a value is safe to copy to a register. If the extension proposed here can only be implemented using MSL that forces values to which pointers are created to not be copied into registers, then this could have a significant performance impact.
One could simply tell users that enabling the extension may have a performance impact. But if I understand correctly, using bindless in any significant way requires enabling the extension.
I'm having a hard time understanding how these two answers fit together:
- proposal: eliminate the aliasing restrictions #5611 (comment)
- [bindless] Add aliasing updates for bindless to WGSL spec #5581 (comment)
@mwyrzykowski In the first comment, you agreed that
if all device-pointer arguments are passed into the MSL entry point via a single argument buffer, then there is no hazard.
But in the second comment, you said that the code example is not well-defined, even though it passes a single device-pointer argument to the MSL entry point, before creating aliasing references to it. Why would a more general feature like an argument buffer cause less trouble for the compiler than a more restricted feature like passing a single buffer directly to the entry point? Would changing the example in #5581 (comment) to use an argument buffer to pass
ztomain_make it well-defined?But in the second comment, you said that the code example is not well-defined,
The second example iirc performs multiple writes to variables which alias to the same at runtime
The assumption for bindless is that any slot in the buffer is only read / written as a single type so it would not have that problem
I discussed the concerns I described in #5611 (comment) with @Kangz, and he pointed out that, if WGSL code that uses pointers that do not alias is translated to platform shader code that uses arrays and index arithmetic, then once the compilers have inlined everything and done constant propagation, they will be able to see that the indices are different, and thus that the array references using those indices are not aliases.
Reacted by mwyrzykowskithus that the array references using those indices are not aliases.
precisely :) apologies if my explanation was not clear
Reacted by Jim Blandy@alan-baker This will be a language extension, not an enable extension, correct?
Reacted by mwyrzykowski@alan-baker This will be a language extension, not an enable extension, correct?
That's the intent, yes.
WIP CTS: gpuweb/cts#4714
Followup to #5501 and #5581
The aliasing section, "11.4.1.2 Aliasing", forbids potential read-write and write-write hazards through pointer parameters to function calls.
This rule was established to ensure safe use of pointer parameters where
If kept, the aliasing restriction will severely limit the utility of bindless and buffer-view proposals. We believe that implementations already have all or most of the machinery to avoid the bad underlying behaviours.
Per the discussions on the above two issues (e.g. here), treat the removal of the aliasing restrictions as its own independent language feature. Formally it is independent of buffer-view and bindless.