proposal: eliminate the aliasing restrictions

[dneto0]

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

• we assumed a fairly direct translation to underlying platform shader languages, and
• there are known hazards in those translations. (e.g. HLSL inout params can be implemented as copy-in-copy-out or as by reference)

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.

[dneto0]

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-aliasing is not even needed so as long as there are no read-write or write-read hazards

Combining 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.

[mwyrzykowski]

Combining 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

[alan-baker]

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:

1. Add a uniformity error if any parameter that must be uniform is aliased at a function call.
2. 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).

[jimblandy]

minutes 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.

[jimblandy]

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?

[jimblandy]

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.

[jimblandy]

@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?