Black-box the BuilderImpl by putting the BuilderImpl into the
from_program.cc file.
Why:
* It means there's only a single definition of all the methods that need
to be maintained, instead of pointlessly splitting code between two
files (.cc / .h).
* It removes all the implementation details from the header.
* It removes a whole bunch of transitive includes, slowing compiles.
* It prevents the temptation for future #includes to
private-implementation details.
* It reduces the amount of symbols declared outside of anonymous
namespaces, reducing symbol polution and the amount of work on the
linker.
Bug: tint:1718
Change-Id: I82838089f784ab003dae4ef06545bba1ca2401cc
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/132321
Commit-Queue: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Remove the direct use of BuilderImpl from TestHelperBase to cut down the amount
of internal state management required by the tests, and removing confusing
conflation between the BuilderImpl and Builder.
This change removes the following methods from TestHelperBase:
* CreateBuilder()
* InjectFlowBlock()
* CreateEmptyBuilder()
* FlowNodeForAstNode()
Tests now just use FromProgram() function for testing AST -> IR.
The downside to the black-box testing is that the per-method granularity of the
unit testing increases to whole FromProgram() granularity. However, my personal
opinion is that this is more than offset by the lack of state leakage from the
implementation to the tests.
Bug tint:1718
Change-Id: Iba2560e0fbcbd3dfb936694e50997d716f09fbd8
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/132960
Kokoro: Ben Clayton <bclayton@google.com>
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
This CL consolidates the various ToInstruction and ToValue methods into
the disassembler. The type output is updated to prefix `:` instead of
surrounding by `()`.
Bug: tint:1718
Change-Id: I69e2d96ffbfe2113932740ce69d0967d29d41541
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/131460
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
This CL removes the `ir::Runtime` and inherits `ir::Instruction` from
`ir::Value`. This means that any `Value` can be an `Instruction`. The
instruction id is used for debugging purposes.
Bug: tint:1895
Change-Id: I2b79cd6721268712d78a47d383a30f82aa3aa07e
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129660
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
This Cl renames the `instr` variables to `inst`.
Bug: tint:1718
Change-Id: Icf3b8c2f612c8dfe4b469d90327fef90ad813a0d
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129460
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
This CL adds support for discard into the IR. The `discard` statement is
handled as an instruction in the current block. The `discard` is a
`demote_to_helper` in WGSL so control flow has to continue after the
discard, it just predicates writes. So, an instruction seems like the
most logical way to express.
Bug: tint:1718
Change-Id: I0d2fb029631523d72a7811d0be0715732427c302
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129200
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
