An expression that is inside an if-statement condition does not have a
"current block", which is what we were using to see if the usage was
inside a continuing block. Use the current statement to find the
containing block instead.
Fixed: chromium:1251664
Change-Id: Icc808ca1cf6a1b51757da8303901fa5ecb693e83
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/65520
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
MSL has a limit on the number of threadgroup memory arguments, so use
a struct to support an arbitrary number of workgroup variables.
This commit introduces a `State` object to this transform, which is
used to track which structs have been cloned eagerly, in order to
avoid duplicating them.
Bug: tint:938
Change-Id: Ia467db186e176a08f160455eab5fd3b3662f56b8
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/65360
Auto-Submit: James Price <jrprice@google.com>
Kokoro: James Price <jrprice@google.com>
Commit-Queue: James Price <jrprice@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Correctly rename fields when combining two or more input structures together into a single input structure.
Bug: chromium:1251009
Change-Id: I0c7ab5ed3116b97035e100d1ef96e772e819f640
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/64545
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: James Price <jrprice@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
This reverts commit af8cd3b7f5.
Reason for revert: breaking roll into Dawn.
Original change's description:
> msl: Use a struct for threadgroup memory arguments
>
> MSL has a limit on the number of threadgroup memory arguments, so use
> a struct to support an arbitrary number of workgroup variables.
>
> Bug: tint:938
> Change-Id: I40e4a8d99bc4ae074010479a56e13e2e0acdded3
> Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/64380
> 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>
TBR=bclayton@google.com,jrprice@google.com,noreply+kokoro@google.com,tint-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: I58a07c4ab7e92bda205e2bbbab41e0b347aeb1e8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: tint:938
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/65162
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Kokoro: Corentin Wallez <cwallez@chromium.org>
MSL has a limit on the number of threadgroup memory arguments, so use
a struct to support an arbitrary number of workgroup variables.
Bug: tint:938
Change-Id: I40e4a8d99bc4ae074010479a56e13e2e0acdded3
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/64380
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>
The overridable constants type can only be deducted from shader, those
passed into `record<USVString, GPUPipelineConstantValue> constants;`
are all double. In dawn pipeline (vulkan backend for exmaple) we need to
do type cast for these double values and passed in to native API
Bug: tint:1155, dawn:1041
Change-Id: I3abb43e61d63f054402ca8d3280b44a833a5f67e
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/64601
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Shrek Shao <shrekshao@google.com>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
The SPIR-V optimizer's representation deduplicates constants
by structural equality. We don't want that for WGSL.
Fixed: tint:1173
Change-Id: I7a3936fcd4803a1cda02e71cbaa7c4be89eba433
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/64701
Auto-Submit: David Neto <dneto@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: David Neto <dneto@google.com>
Update one test to avoid this error.
Fixed: tint:1179
Change-Id: Id41b0eb0f404648de4e86a835fe43f1729cb4696
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/64464
Auto-Submit: David Neto <dneto@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: David Neto <dneto@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Use a threadgroup memory argument for any workgroup variable that
contains a matrix.
The generator now provides a list of threadgroup memory arguments for
each entry point, so that the runtime knows how many bytes to allocate
for each argument.
Bug: tint:938
Change-Id: Ia4af33cd6a44c4f74258793443eb737c2931f5eb
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/64042
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: James Price <jrprice@google.com>
Dawn needs to know if a given entry point uses this builtin, so that
it can pass this information via a root constant for HLSL.
Bug: tint:752
Change-Id: I8bcd3a343db16774ffedd9db9813451f97f10aba
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/64040
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
For HLSL, use the new NumWorkgroupsFromUniform transform, and expose
the binding point to use for the generated uniform as a backend
option.
The MSL mapping is trivial, and it was already implemented for WGSL
and SPIR-V.
Bug: tint:752
Change-Id: I4bd37b5d26181629d72b152fe064a60caf8ecdc5
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63962
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
This transform scans entry points for struct parameters that contain
the num_workgroups builtin, and replace accesses to these members with
a value loaded from a uniform buffer.
This will be used by the HLSL backend to implement the num_workgroups
builtin.
Bug: tint:752
Change-Id: Iefab3b14af8a08a6135348fded368a06d932e915
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63961
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
The subsequent commits will implement this for all remaining backends.
Bug: tint:752
Change-Id: Id26f920fea93b5678466705612dcbfc229dc878a
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63921
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: James Price <jrprice@google.com>
Ensure that remapped access modes are valid enum values.
NB: This is hard to test, as UBSan flags an out-of-range enum value as
a hard error.
Fixed: chromium:1248754, chromium:1248755
Change-Id: I2e686843134e6a285fb8316a1960fc4eadff2a93
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/64120
Auto-Submit: James Price <jrprice@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
We were sorting the inputs twice.
Also make use the UniqueVector::operator std::vector() to simplify the code a little.
Doesn't appear to change any tests.
Just spotted while looking through code.
Change-Id: Iddb433b9c8c429f32b40a10cf466c712fde7a317
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63701
Auto-Submit: Ben Clayton <bclayton@google.com>
Commit-Queue: David Neto <dneto@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: David Neto <dneto@google.com>
Invoke the required transforms directly in the SPIR-V backend.
Change-Id: I78dc667d5c4c9c1d4da13ef5a99ece831c103982
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63801
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Invoke the required transforms directly in the HLSL backend.
Change-Id: I9465fef375dd4dad6a91c1e7e16ede6401b9bfc0
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63800
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Will requires updating the WGSL spec, which currently has rules looser than SPIR-V.
Fixed: tint:1167
Bug: chromium:1246163
Change-Id: Ie8fcfabc0bb89c7fb69c345475ff99c07fa04172
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63560
Commit-Queue: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: David Neto <dneto@google.com>
Auto-Submit: Ben Clayton <bclayton@google.com>
Invoke the required transforms directly in the MSL backend.
Change-Id: Id8026b1a64415fbe363f8f8a5790e8216cd12c68
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63620
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: James Price <jrprice@google.com>
This CL changes the way that the resolver traverses expressions to avoid stack overflows for deeply nested expressions.
Instead of having the expression resolver methods call back into
Expression(), add a TraverseExpressions() method that collects all the
expression nodes with a simple DFS.
This currently only changes the way that Expressions are traversed. We
may need to do the same for statements.
Bug: chromium:1246375
Change-Id: Ie81905da1b790b6dd1df9f1ac42e06593d397c21
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63700
Auto-Submit: Ben Clayton <bclayton@google.com>
Reviewed-by: David Neto <dneto@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
When the magnitude is zero, then we don't care about the magnitude
of the exponent. The result value is always zero, without emitting
an error.
Fixed: tint:1166
Change-Id: I303d7c336e7ea42719571854f0a22cbfd19da32c
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63520
Kokoro: Kokoro <noreply+kokoro@google.com>
Auto-Submit: David Neto <dneto@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>
This is easy to do while we are processing builtins in the main
transform now that we use wrapper functions.
This is step towards removing the sanitizers completely.
Change-Id: If5472ce552e3cce1e5905916eeffa8fef90461c9
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63585
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
This is the HandleModuleScopeVars() part of the MSL sanitizer moved
verbatim to a standalone transform. The transform code is unchanged,
but some expected test outputs are different as this is now tested in
isolation instead of along with the rest of the sanitizer transforms.
This is step towards removing the sanitizers completely.
Change-Id: I7be826e2119451fc2ce2891740cc94f978e7d5a1
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63583
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Use this from the HLSL and SPIR-V sanitizers, instead of duplicating
this logic for them.
This is step towards removing the sanitizers completely.
Change-Id: Ifa9f23d84fd3505d30a928c260181a699c5f1783
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63582
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
No new tests or any changes, just moving to a separate file in
preparation for adding lots more of these tests soon.
Change-Id: Iaa7eef52384e702c395a6db312fef19e22507644
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63580
Kokoro: Kokoro <noreply+kokoro@google.com>
Auto-Submit: James Price <jrprice@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Commit-Queue: James Price <jrprice@google.com>
During HexFloat parsing, if exponent was too large, we would overflow
the signed integer being used to store its value. We now use an uint32_t
to avoid UB, then convert to int32_t when it's safe to do so.
Also error out if the input exponent is > INT_MAX - 127, which ensures
we will not wrap around and produce an invalid result when adding the
exponent bias of 127.
Bug: chromium:1240048
Bug: tint:1150
Change-Id: I1b57b2c965358b803ebb68ea70b76e759cdd3939
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63120
Reviewed-by: David Neto <dneto@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>
- Locally tested with each of the 6 options turned off alone, and fixed
the build.
- Added an incremental build to the Linux Kokoro build with all these
flags disabled, which will help catch a subset of build issues related
to these flags.
Bug: tint:1139
Change-Id: I40eaaea31d88879aa19eac3f17c47b7e7d7a477f
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63241
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>
Adds casts to uint64_t so that a comparison between size_t and the
largest possible uint32_t value does not lead to a tautological warning
when building for i386.
Fixes tint:1162
Change-Id: Ib18140805d443d51bb7e48c9e345b21b9d5651fb
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63440
Auto-Submit: Alastair Donaldson <afdx@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Alastair Donaldson <afdx@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Refactors the CMake rules for the tint fuzzers so that when OSS-Fuzz is
controlling the build process no specific fuzzer options are used. This
allows OSS-Fuzz to fully control the fuzzing engine.
Change-Id: Ic4423b981df12e66a14ca8f53c97168ac28bfa39
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63342
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Alastair Donaldson <afdx@google.com>
Auto-Submit: Alastair Donaldson <afdx@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Change ast::Array to use an ast::Expression for its `size` field. The
WGSL frontend now parses the array size as an `primary_expression`,
and the Resolver is responsible for validating the expression is a
signed or unsigned integer, and either a literal or a non-overridable
module-scope constant.
The Resolver evaluates the constant value of the size expression, and
so the resolved sem::Array type still has a constant size as before.
Fixed: tint:1068
Fixed: tint:1117
Change-Id: Icfa141482ea1e47ea8c21a25e9eb48221f176e9a
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63061
Auto-Submit: James Price <jrprice@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: James Price <jrprice@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
WGSL only allows literals and identifiers as arguments to
workgroup_size.
Also, change "parameter" to "argument" in the workgroup_size error
messages.
Change-Id: Ibd252a7c2f08464d9cdea62707e64a8e4f12893a
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63320
Auto-Submit: James Price <jrprice@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
We can just use the top-level EmitExpression() here.
Change-Id: I3ab346525b6d49f6a986abb5d89aa792171c1db3
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63060
Auto-Submit: James Price <jrprice@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
The clusterfuzz fuzzers are attempting to change the access control of a uniform variable, which produces a program that does not validate.
Create an error diagnostic tagged with diag::System::Transform, which the fuzzers recognise as being invalid configuration to the transform.
Fixed: chromium:1244999
Change-Id: I2d4f2dfd4f2218ac81172003872494acb027323b
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63141
Auto-Submit: Ben Clayton <bclayton@google.com>
Commit-Queue: David Neto <dneto@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: David Neto <dneto@google.com>
Fixes:tint:1124
Change-Id: I6cab684423081889d27b266628089c55918e1f9f
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/62320
Auto-Submit: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: David Neto <dneto@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
SPIR-V supports them but WGSL does not.
Fixed: chromium:1230976
Change-Id: I27dbbf4a0f584bcff7355bf513bbd2b924dc349b
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/62922
Auto-Submit: David Neto <dneto@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: James Price <jrprice@google.com>
Commit-Queue: James Price <jrprice@google.com>
Never create semantic types on the stack.
Always use ProgramBuilder::create().
These stack pointers have a tendency of being stored, either by other
types as sub-types, or by maps (see associated bug).
Also, there's a lot of logic that assumes that semantic types are
de-duplicated, and that you can compare pointers. Creating new instances
on the stack will break this in exciting ways.
Fixed: chromium:1243944
Change-Id: I40a652f8c424030106adad2e6531287af13c8714
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/62943
Auto-Submit: Ben Clayton <bclayton@google.com>
Commit-Queue: David Neto <dneto@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: David Neto <dneto@google.com>
While looking ahead to determine if a token is an integer, check the
number of digits to make sure that it can actually fit in the internal
representation.
This is an optimization on the existing code, to cause an early exit
and prevent pathological cases with huge integers from consuming too
much processing time, when they will never succeed.
From a functional perspective this has not effect on whether or not a
token will be accepted as an integer, so almost all of the tests do no
need an update. The one exception is a case where the lexer now
catches the invalid integer earlier in the tokenization, so the error
message is a shorter.
This does not handle the equivalent problem for float literals, though
I believe that only exists for non-hex floats.
BUG=chromium:1240715
Change-Id: I27e43711d5f5eda1d54a4128ba514f810abd0313
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/62280
Auto-Submit: Ryan Harrison <rharrison@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>