Not currently called (nothing currently attaches ast::Type nodes to the AST), but implements some of the boilerplate that'll be shortly required.
This change also removes a bunch of duplicated enumerators from the sem namespace for their counterpart in the ast namespace.
Bug: tint:724
Change-Id: I0372a9f4eca2f9357ff161e7ec1b67eae1c4c8f6
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/48603
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Copy all of the type classes from src/type into ast.
Required the merging of:
* type::Struct into the existing ast::Struct - ast::Struct now has a name.
* type::AccessControl into the existing ast::AccessControl enumerator - The old ast::AccessControl enumerator is now ast::AccessControl::Access
Bug: tint:724
Change-Id: Ibb950036ed551ec769c6d3d2c8fb411809cf6931
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/48383
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Handle the case where the OpBranchConditional in a loop header
branches to two distinct blocks inside the loop construct.
This is an if-selection in disguise.
Create an kIfSelection with the same set of blocks as the kLoop,
and with the continue target as the merge.
Fixed: tint:524
Change-Id: I5150d19a2b4388da409e2da6e68ffafdc5d21a9a
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/47560
Commit-Queue: David Neto <dneto@google.com>
Auto-Submit: David Neto <dneto@google.com>
Reviewed-by: Alan Baker <alanbaker@google.com>
EmitControlBarrier() was calling MakeOperand() to create ast::Expressions that held a ScalarConstructorExpression, which held a IntLiteral.
The literal value was then taken, and the rest was discarded.
Detached AST nodes will become an ICE, so do the work to find the literal value.
Bug: tint:469
Change-Id: I522bfe8db84e853e189c714b18598feb0d49e58b
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/48049
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: James Price <jrprice@google.com>
When finding the true-head, false-head, and potentially the
premerge-head blocks of an if-selection, there was an overly
aggressive check for the true-branch or false-branch landing
on a merge block interior to the if-selection. The check was
determining if the merge block actually corresponded to the selection
header in question. If not, then it was throwing an error.
The bug was that this check must be performed only if the
target in question is actually inside the selection body.
There are cases where the target could represent a structured
exit, e.g. to an enclosing loop's merge or continue, or
an enclosing switch construct's merge.
There is still a latent bug: if either the true branch
or false branch represent such a kLoopBreak, kLoopContinue, or
kSwitchBreak edge, then those are not properly generated.
That will be fixed in a followup CL.
Bug: tint:243, tint:494
Change-Id: I141cce07fa0a1dfe5fad20dd2989315e4cd7b688
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/47482
Auto-Submit: David Neto <dneto@google.com>
Commit-Queue: Alan Baker <alanbaker@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Alan Baker <alanbaker@google.com>
Use TINT_ICE() where we have diagnostics, TINT_ASSERT() where we do not.
Change-Id: Ic6e842a7afdd957654c3461e5d03ecec7332e6f9
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/46444
Commit-Queue: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
This was updated/clarified by the SPIR WG.
Bug: tint:3
Change-Id: Ie4c503f0e5f80ffeabada9c526375588e81a5ceb
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/45740
Auto-Submit: David Neto <dneto@google.com>
Commit-Queue: Alan Baker <alanbaker@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Alan Baker <alanbaker@google.com>
Add a return type decoration list field to ast::Function.
Bug: tint:513
Change-Id: I41c1087f21a87731eb48ec7642997da5ae7f2baa
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/44601
Commit-Queue: James Price <jrprice@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Remove the decoration groupings (Array, Function, Struct,
StructMember, Type, Variable), such that all *Decoration classes now
subclass ast::Decoration directly. This allows for decorations to be
used in multiple places; for example, builtin decorations are now
valid for both variables and struct members.
Checking that decoration lists only contain decorations that are valid
for the node that they are attached to is now done inside the
validator.
Change-Id: Ie8c0e53e5730a7dedea50a1dec8f26f9e7b00e8d
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/44320
Commit-Queue: James Price <jrprice@google.com>
Reviewed-by: Ben Clayton <bclayton@chromium.org>
The readers must not produce invalid ASTs.
If readers cannot produce a valid AST, then they should error instead.
If a reader does produce an invalid AST, this change catches this bad behavior early, significantly helping identify the root of the broken logic.
IsValid() made a bit more sense in the days where the AST was mutable, and was constructed by calling setters on the nodes to build up the tree.
In order to detect bad ASTs, IsValid() would have to perform an entire AST traversal and give a yes / no answer for the entire tree. Not only was this slow, an answer of 'no' didn't tell you *where* the AST was invalid, resulting in a lot of manual debugging.
Now that the AST is fully immutable, all child nodes need to be built before their parents. The AST node constructors now become a perfect place to perform pointer sanity checking.
The argument for attempting to catch and handle invalid ASTs is not a compelling one.
Invalid ASTs are invalid compiler behavior, not something that should ever happen with a correctly functioning compiler.
If this were to happen in production, the user would be utterly clueless to _why_ the program is invalid, or _how_ to fix it.
Attempting to handle invalid ASTs is just masking a much larger problem.
Let's just let the fuzzers do their job to catch any of these cases early.
Fixed: chromium:1185569
Change-Id: I6496426a3a9da9d42627d2c1ca23917bfd04cc5c
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/44048
Commit-Queue: Ben Clayton <bclayton@chromium.org>
Reviewed-by: David Neto <dneto@google.com>
All includes from .cc to .h are preserved, even when transitively included.
It's clear that there are far too many includes in header files, and we should be more aggressive with forward declarations. tint:532 will continue to track this work.
There are, however, plenty of includes that have accumulated over time which are no longer required directly or transitively, so this change starts with a clean slate of *required* includes.
Bug: tint:532
Change-Id: Ie1718dad565f8309fa180ef91bcf3920e76dba18
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/44042
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
to TINT_INSTANTIATE_TYPEINFO()
ClassID isn't a thing any more.
Change-Id: Ie1c0d4a95e58ef7166d3cab5ef733a2dfc702345
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/42921
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: James Price <jrprice@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
This is the first step in being able to read code generated
by Clspv.
Actively ignore the instructions instead of applying stripping
transform before hand. That way we have a chance at properly counting
instructions, which helps produce better diagnostics.
Bug: tint:3
Change-Id: I82bde88897485380d70dc8b287c3843eae5489b6
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/41641
Auto-Submit: David Neto <dneto@google.com>
Commit-Queue: dan sinclair <dsinclair@chromium.org>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
This generates intermediate variable to stuff the component into,
then a constant definition to evaluate the result for later use.
Bug: tint:3
Change-Id: If2e6bb24e2b1e621c3602509eb3237c40f53897b
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/41360
Auto-Submit: David Neto <dneto@google.com>
Commit-Queue: dan sinclair <dsinclair@chromium.org>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
* Add support for data unpacking intrinsics
* spir-v reader
* type determiner
* intrinsic table
* spir-v, hlsl and msl writers
Bug: tint:341
Change-Id: I8f40d19d59a4699af75cd579fe8398c735a77a59
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/41320
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Commit-Queue: Alan Baker <alanbaker@google.com>
This allows us to create a semantic::Intrinsic class that holds more information about the particular intrinsic overload.
Change-Id: I180ddb507ebc92172badfdd3a59af346f96e1f02
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/40500
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
TODO: passing pointer to them as a function parameter
Bug: tint:471
Change-Id: Ibd55bdc77a2bfb0f5712dd9bf332910999b8d0d1
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/40123
Commit-Queue: David Neto <dneto@google.com>
Auto-Submit: David Neto <dneto@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
* Fix how the HLSL writer determines how to use a RWByteAddressBuffer
* Fix how the HLSL writer decides the register space for a storage
variable
* Fix inference of hlsl format in the tint executable
* Add support for data packing intrinsics
* type determination
* validation
* writers
* spirv reader
Bug: tint:340, tint:473, tint:474
Change-Id: I45dc8fd7c6f9abc7d30f617c7e3d713d7965b76e
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/40342
Commit-Queue: Alan Baker <alanbaker@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
TODO: support sample_id declared with signed integer store
type, and then having the pointer passed to a helper function.
Bug: tint:471
Change-Id: Iac303ff6118b2d2d518e5070a8d589dcd3616f39
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/40020
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Auto-Submit: David Neto <dneto@google.com>
semantic::Call derives from semantic::Expression, and Type() is the return type of the function
Pull the mutable semantic field from ast::Identifier and into a new semantic nodes.
Have the TypeDeterminer create these new semantic nodes.
Note: This change also fixes the node that holds the semantic information for a call.
Previously this was on the identifier, and this is now correctly on the CallExpression.
The identifier of the CallExpression should resolve to the target function, not the return type.
Functions can currently be represented as a type, and the identifier of a CallExpression now has no semantic information.
Bug: tint:390
Change-Id: I03521da5634815d35022f45ba521372cbbdb6bc7
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/40065
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: David Neto <dneto@google.com>
With the ast::Module::Functions().
Also remove pointless calls to td.Determine() that will automatically be
done when the program is built.
Change-Id: Ia7506e430b04d91d4f6b02fb6b678d0ea9912bcd
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/39900
Commit-Queue: dan sinclair <dsinclair@chromium.org>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
It queries the dimensions and array levels of a sampled image.
Bug: tint:109
Fixed: tint:423
Change-Id: Ia9ac0ee84b0282dbde8729a1698c9b21943723d2
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/39682
Commit-Queue: David Neto <dneto@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Auto-Submit: David Neto <dneto@google.com>
Will hold the mutable fields that currently reside in the otherwise immutable-AST.
Change the AST string methods to accept a `const semantic::Info&`. This is required as some nodes include type-resolved information in their output strings.
Bug: tint:390
Change-Id: Iba494a9c5645ce2096da0a8cfe63a4309a9d9c3c
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/39003
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
WGSL requires an explicit level-of-detail for textureLoad
for sampled textures and depth textures
Fixed: tint:462
Change-Id: I43758b002da91af9901d12664861ace971833020
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/38828
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Commit-Queue: dan sinclair <dsinclair@chromium.org>
Auto-Submit: David Neto <dneto@google.com>
Program is now immutable*, and remains part of the public Tint
interface.
ProgramBuilder is the mutable builder for Programs, and is not part of
the public Tint interface. ast::Builder has been folded into
ProgramBuilder.
Immutable Programs can be cloned into a mutable ProgramBuilder with
Program::CloneAsBuilder().
Mutable ProgramBuilders can be moved into immutable Programs.
* - mostly immutable. It still has a move constructor and move
assignment operator - required for practical usage - and the
semantic information on AST nodes is still mutable.
Bug: tint:390
Change-Id: Ia856c50b1880c2f95c91467a9eef5024cbc380c6
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/38240
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Enforce all places where Dawn passes in or returns a ast::Module, now takes a `const Program* ` or returns a `Program`.
As the end goal of all this is to have immutable Programs, all Program inputs take a pointer instead of moving the actual object.
As consumers of a Program are now all const, we have to const_cast to work around all the places we've been incorrectly mutating a ast::Module.
These const_casts are temporary, and will be fixed in the next set of changes.
Depends on https://dawn-review.googlesource.com/c/dawn/+/38522
Bug: tint:390
Change-Id: Ie05b112b16134937d1b601e9b713ea4ec4e1c677
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/38541
Reviewed-by: dan sinclair <dsinclair@chromium.org>
