This is now a well-defined term in the WGSL spec, so we should use it.
Change-Id: Icc46a77f0a465afbfd39cdaec84e506b143c8c0c
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/109220
Commit-Queue: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Auto-Submit: James Price <jrprice@google.com>
Now that expressions can only ever have the `Next` behavior,
short-circuiting operators will always reconverge.
Change-Id: Ib9fe4c774191b8a304fa7f7a6eafdfa6c6e6f18a
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/108202
Kokoro: Kokoro <noreply+kokoro@google.com>
Auto-Submit: James Price <jrprice@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: James Price <jrprice@google.com>
We now use the MergeReturn transform for SPIR-V, which is the only
backend that requires special handling to meet these function call
reconvergence requirements.
Fixed: tint:1627, tint:1726
Change-Id: I25f848f4b9ff0fd301b8a27a220bb09cdb2867ca
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/107364
Commit-Queue: James Price <jrprice@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
This CL adds support for `break-if` to Tint.
Bug: tint:1633, tint:1451
Change-Id: I30dfd62a3e09255624ff76ebe0cdd3a3c7cf9c5f
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/106420
Auto-Submit: Dan Sinclair <dsinclair@chromium.org>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: dan sinclair <dsinclair@google.com>
Added support for reporting when pointer parameters point to non-uniform
values. Also add support for binary expressions results that may be
non-uniform.
Bug: chromium:1374534
Change-Id: Ia51557e3a984c69a39f2878c964bf07085599809
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/106560
Commit-Queue: Antonio Maiorano <amaiorano@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
This CL catches up the internals (along with a few error messages) to
say `initializer` instead of `constructor.
Bug: tint:1600
Change-Id: I8e56572c310d77da1130380bdd32b334f27c8e46
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/106462
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Auto-Submit: Dan Sinclair <dsinclair@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>
Variables can be declared in more than just BlockStatement.
For example, for-loops can declare a variable.
Change this to be a map instead of a vector. This helps with lookups.
Change-Id: Ic9429425af70e9535c21cc0875b875f145724266
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/104040
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
This CL updates the internals to use AddressSpace instead of the old
StorageClass name.
Bug: tint:1404
Change-Id: Iecc208e839453437f4d630f65e0152206a52db7e
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/104420
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
Auto-Submit: Dan Sinclair <dsinclair@chromium.org>
These have been warnings for multiple months.
Time to properly turn this on.
Bug: tint:880
Change-Id: I3b38f672309b5acd48c12a38dc5a1675f3c62470
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/103480
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
This is what it is called in the spec, and avoids confusion with the builtin functions.
Change-Id: I5cd4a250351c10928e90b640a8c68c7834bcf2a0
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/97200
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
The frontends do not currently emit these, nor do the backends currently
handle them.
Bug: tint:1580
Change-Id: I469a5379663c2802145b28a94f5c1e348cc14ff3
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/94605
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: David Neto <dneto@google.com>
Add the new classes:
* `ast::Let`
* `ast::Override`
* `ast::Parameter`
* `ast::Var`
Limit the fields to those that are only applicable for their type.
Note: The resolver and validator is a tangled mess for each of the
variable types. This CL tries to keep the functionality exactly the
same. I'll clean this up in another change.
Bug: tint:1582
Change-Id: Iee83324167ffd4d92ae3032b2134677629c90079
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/93780
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Commit-Queue: Ben Clayton <bclayton@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
With abstract materialization, any ast::Expression may map to the new
sem::Materialize node. Because of this, we can't assume that an
ast::CallExpression maps to a sem::Call, as it might be wrapped by a
sem::Materialize.
Remove the mapping, and fix up all the code that was relying on this.
Fixes are done by either:
• Calling `UnwrapMaterialize()->As<sem::Call>()` on the semantic
expression. This is done when the logic may assume it's possible for
the expression to be a Materialize node.
• Using the explicit sem::Info::Get<sem::Call>() template argument to
cast the semantic type to sem::Call. This is done when the logic
either knows it is impossible for the expression to be a Materialize.
The backends have been stubbed, as we'll want to emit the constant value
for these nodes. It's likely that we'll just use the FoldConstants
transform to strip all Materialize nodes from the tree. For now, be
defensive.
Bug: tint:1504
Change-Id: If9231b300fc30c7fe886c17a804ead8ee2988285
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/90533
Commit-Queue: Ben Clayton <bclayton@chromium.org>
Reviewed-by: David Neto <dneto@google.com>
* Extract ast::Enable::ExtensionKind to ast::Extension.
* Move the parsing out of ast::Enable and next to ast/extension.h
* Change the ast::Enable constructor to take the Extension, instead of
a std::string. It's the WGSL parser's responsibility to parse, not the
AST nodes.
* Add ProgramBuilder::Enable() helper.
* Keep ast::Module simple - keep track of the declared AST Enable nodes,
don't do any deduplicating of the enabled extensions.
* Add the de-duplicated ast::Extensions to the sem::Module.
* Remove the kInternalExtensionForTesting enum value - we have kF16
now, which can be used instead for testing.
* Rename kNoExtension to kNone.
Bug: tint:1472
Change-Id: I9af635e95d36991ea468e6e0bf6798bb50937edc
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/90523
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
If the CallSiteRequiredToBeUniform tag is present, add the edge from
RequiredToBeUniform to a new diagnostic node for the function call,
instead of to the control flow coming out of the function call. Doing
the latter causes a false positive when a function both requires
uniform control flow and causes non-uniform control flow.
Bug: tint:880
Change-Id: Icade8f76302e8c21529502f5f945f1981acfc45a
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/90582
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Auto-Submit: James Price <jrprice@google.com>
When importing Dawn into Tint:
error: [chromium-style] auto variable type must not deduce to a raw pointer type.
Change-Id: I6ff4451a5519c38b18eb8d96f6bc82b8090077f8
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/90500
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: James Price <jrprice@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Fixes a stack overflow when traversing particularly deep graphs.
This changes the iteration order which changes some of the diagnostic
notes, but the diagnostics are still correct and deterministic so it
does not matter.
Fixed: chromium:47418
Change-Id: I2def633b6d96d1525027f7929b0fa0a6fba0efeb
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/90140
Auto-Submit: James Price <jrprice@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Add additional nodes to capture places where control flow is changed
(if, switch, for, short-circuiting op, function call), and use these
to show the actual point at which control flow became non-uniform as a
result of a non-uniform value.
Do this recursively, to capture cases where control flow becomes
non-uniform after a function call statement.
Bug: tint:880
Change-Id: Ied92d690f98a5c11a1892eef500a50d0f123943d
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/89862
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
If the function has no return statements, we need to do this to
capture the potential non-uniformity coming from nested function
calls.
This also removes the need to add explicit edges for discard
statements, so remove them.
Bug: tint:880
Change-Id: I88b1132faf35a6d36460ef353912f77a15f8abaa
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/89861
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Show the original source of non-uniformity when producing errors from
the uniformity analysis.
Bug: tint:880
Change-Id: Id386ae8fa5ff1b1443d54c0b5ef12ab76b3b3f13
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/89723
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
When producing an error from the uniformity analysis, add notes to
show the underlying reason for the uniformity requirement.
For function calls that are required-to-be-uniform, show the innermost
builtin call that has the requirement.
For function parameters that are required-to-be-uniform, recurse into
that function to show where its requirement comes from.
Add some new tests to specifically test the error messages.
Bug: tint:880
Change-Id: Ib166fdeceaffb156a3afc50ebc5a4ad0860dc002
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/89722
Reviewed-by: Ben Clayton <bclayton@google.com>
Move the control flow graphs to `FunctionInfo` so that they are not
destroyed when we finish processing the function.
This will make it easier to produce more detailed diagnostics for
uniformity issues, which will be coming in subsequent CLs.
There is no functional change in this CL.
Bug: tint:880
Change-Id: I1322fb54b16bd1c660799a62435fbdcd7fb39cb2
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/89822
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
This implements the uniformity analysis as currently described in the
WGSL specification. Uniformity issues are presented as warnings, and
will be switched to errors in a future release.
A follow-up patch will improve the error messages, which currently
just show the point at which a uniformity was detected.
In a future release, once we have obtained initial feedback from
users, uniformity issues will become errors.
Bug: tint:880
Change-Id: I7d0b3080932c786c5d50b55720fec6d19f00d356
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/88368
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Alan Baker <alanbaker@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
