| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- add missing canonicalization pattern to fold memref_cast + dim to
dim (needed to propagate constant when folding a dynamic shape to
a static one)
- also fix an outdated/inconsistent comment in StandardOps/Ops.td
Signed-off-by: Uday Bondhugula <uday@polymagelabs.com>
Closes tensorflow/mlir#126
COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/126 from bondhugula:quickfix 4566e75e49685c532faffff91d64c5d83d4da524
PiperOrigin-RevId: 269020058
|
|
|
|
|
|
| |
This allows for users other than those on the command line to apply a textual description of a pipeline to a given pass manager.
PiperOrigin-RevId: 269017028
|
|
|
|
| |
PiperOrigin-RevId: 269000237
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SPIR-V recently publishes v1.5, which brings a bunch of symbols
into core. So the suffix "KHR"/"EXT"/etc. is removed from the
symbols. We use a script to pull information from the spec
directly.
Also changed conversion and tests to use GLSL450 instead of
VulkanKHR memory model. GLSL450 is still the main memory model
supported by Vulkan shaders and it does not require extra
capability to enable.
PiperOrigin-RevId: 268992661
|
|
|
|
|
|
| |
These directives were temporary during the generalization of FunctionPass/ModulePass to OpPass.
PiperOrigin-RevId: 268970259
|
|
|
|
| |
PiperOrigin-RevId: 268968004
|
|
|
|
|
|
| |
This allows for the use of multiple ParallelDiagnosticHandlers without having them conflict with each other.
PiperOrigin-RevId: 268967407
|
|
|
|
|
|
|
| |
Before this change, it only reports expected type but not exact type, so
it's hard to troubleshoot.
PiperOrigin-RevId: 268961078
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
strings.
This allows for explicitly specifying the pipeline to add to the pass manager. This includes the nesting structure, as well as the passes/pipelines to run. A textual pipeline string is defined as a series of names, each of which may in itself recursively contain a nested pipeline description. A name is either the name of a registered pass, or pass pipeline, (e.g. "cse") or the name of an operation type (e.g. "func").
For example, the following pipeline:
$ mlir-opt foo.mlir -cse -canonicalize -lower-to-llvm
Could now be specified as:
$ mlir-opt foo.mlir -pass-pipeline='func(cse, canonicalize), lower-to-llvm'
This will allow for running pipelines on nested operations, like say spirv modules. This does not remove any of the current functionality, and in fact can be used in unison. The new option is available via 'pass-pipeline'.
PiperOrigin-RevId: 268954279
|
|
|
|
|
|
| |
These refer to ranked tensors, but are actually applicable to any shaped type
PiperOrigin-RevId: 268931789
|
|
|
|
| |
PiperOrigin-RevId: 268877189
|
|
|
|
| |
PiperOrigin-RevId: 268859399
|
|
|
|
| |
PiperOrigin-RevId: 268783645
|
|
|
|
|
|
|
|
| |
Use variable captures to make constant folding tests less sensitive to printer/parser implementation details.
See guidelines at https://github.com/tensorflow/mlir/blob/master/g3doc/TestingGuide.md
PiperOrigin-RevId: 268780812
|
|
|
|
|
|
|
|
| |
This CL adds support for serializing and deserializing spv.loop ops.
This adds support for spv.Branch and spv.BranchConditional op
(de)serialization, too, because they are needed for spv.loop.
PiperOrigin-RevId: 268536962
|
|
|
|
|
|
|
|
|
|
|
| |
This better reflects how this kind of expressions is used and avoids the
potential confusion since the expression can take negative values. Term
expressions comprise dimensions, symbols and stripe expressions. In an SDBM
domain, a stripe expression always corresponds to a variable, input or
temporary. This expression can appear anywhere an input variable can,
including on the LHS of other stripe expressions.
PiperOrigin-RevId: 268486066
|
|
|
|
| |
PiperOrigin-RevId: 268443146
|
|
|
|
| |
PiperOrigin-RevId: 268436116
|
|
|
|
|
|
| |
apparently reversed.
PiperOrigin-RevId: 268395163
|
|
|
|
| |
PiperOrigin-RevId: 268361054
|
|
|
|
|
|
|
|
| |
If the composite is a constant, we can fold it away. This only
supports vector and array constants for now, given that struct
constant is not supported in spv.constant yet.
PiperOrigin-RevId: 268350340
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since we apply nudging for the zero point to make sure the nudged zerop points
can be in the range of [qmin, qmax], the constraint that rmin / rmax should
stride zero isn't necessary.
This also matches the documentation of tensorflow's FakeQuantWithMinMaxArgs op,
where min and max don't need to stride zero:
https://www.tensorflow.org/api_docs/python/tf/quantization/fake_quant_with_min_max_args
PiperOrigin-RevId: 268296285
|
|
|
|
|
|
| |
This is also to add the test to the fakeQuantAttrsToType for per-channel fake quant.
PiperOrigin-RevId: 268260032
|
|
|
|
| |
PiperOrigin-RevId: 268173638
|
|
|
|
|
|
| |
Address GCC error: extra qualification not allowed [-fpermissive]
PiperOrigin-RevId: 268133737
|
|
|
|
| |
PiperOrigin-RevId: 268132321
|
|
|
|
|
|
|
|
|
|
|
| |
* Add GraphTraits that treat a block as a graph, Operation* as node and use-relationship for edges;
- Just basic graph output;
* Add use iterator to iterate over all uses of an Operation;
* Add testing pass to generate op graph;
This does not support arbitrary operations other than function nor nested regions yet.
PiperOrigin-RevId: 268121782
|
|
|
|
|
|
|
| |
Comparing to the existing quant.const_fake_quant op, the min and max attributes
of this new op is for each channel of last dimension of the input.
PiperOrigin-RevId: 268093722
|
|
|
|
| |
PiperOrigin-RevId: 268090906
|
|
|
|
|
|
|
|
| |
For per channel fake quant attributes, the returned type should be
UniformQuantizedPerAxisType. Currently, this method isn't under test because we
haven't added the quant_ConstFakeQuantPerAxis op and the convert method.
PiperOrigin-RevId: 268084017
|
|
|
|
|
|
| |
Some compilers will try to auto-generate the destructor, instead of using the user provided destructor, when creating a default move constructor.
PiperOrigin-RevId: 268067367
|
|
|
|
| |
PiperOrigin-RevId: 268041584
|
|
|
|
| |
PiperOrigin-RevId: 268041263
|
|
|
|
|
|
| |
This allows for parallelizing across pipelines of multiple operation types. AdaptorPasses can now hold pass managers for multiple operation types and will dispatch based upon the operation being operated on.
PiperOrigin-RevId: 268017344
|
|
|
|
|
|
| |
Just formatting and better lit tests, no functional change.
PiperOrigin-RevId: 267942907
|
|
|
|
|
|
|
|
|
| |
This method parses an operation in its generic form, from the current parser
state. This is the symmetric of OpAsmPrinter::printGenericOp(). An immediate
use case is illustrated in the test dialect, where an operation wraps another
one in its region and makes use of a single-line pretty-print form.
PiperOrigin-RevId: 267930869
|
|
|
|
|
|
| |
This is done via a new set of instrumentation hooks runBeforePipeline/runAfterPipeline, that signal the lifetime of a pass pipeline on a specific operation type. These hooks also provide the parent thread of the pipeline, allowing for accurate merging of timers running on different threads.
PiperOrigin-RevId: 267909193
|
|
|
|
|
|
|
|
| |
This is the only example for overriding this interface in the repo, let's
try to make it right as it may be taken as a reference when implemented in
other dialects
PiperOrigin-RevId: 267811123
|
|
|
|
|
|
|
| |
This will allow clients to implement a different collection strategy on these
values, including collecting each uses within the region for example.
PiperOrigin-RevId: 267803978
|
|
|
|
|
|
|
|
|
|
|
|
| |
- the JIT codegen was being run at the default -O0 level; instead,
propagate the opt level from the cmd line.
Signed-off-by: Uday Bondhugula <uday@polymagelabs.com>
Closes tensorflow/mlir#123
COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/123 from bondhugula:jit-runner 3b055e47f94c9a48bf487f6400787478738cda02
PiperOrigin-RevId: 267778586
|
|
|
|
| |
PiperOrigin-RevId: 267774506
|
|
|
|
|
|
|
| |
This doc serves as a manual for table-driven declarative rewrite rules.
It lists all the details regarding supported mechanisms.
PiperOrigin-RevId: 267761702
|
|
|
|
| |
PiperOrigin-RevId: 267650411
|
|
|
|
|
|
| |
The current restrictions on dim/symbols require a top-level symbol for the conservative case of a non-affine region. This should be relaxed in the future.
PiperOrigin-RevId: 267641838
|
|
|
|
|
|
|
| |
Closes tensorflow/mlir#109
COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/109 from nmostafa:nmostafa/AffineIfOp 7dbf2115f0092ffab26381ea8704aa05a0253971
PiperOrigin-RevId: 267633077
|
|
|
|
|
|
|
| |
View descriptors are converted to *pointer to* LLVM struct to avoid ABI issues related to C struct packing. This creates unnecessary complexity and hampers unification with memrefs.
Instead, this CL makes view descriptors convert to LLVM struct (as it was originally) and promotes all structs to pointers right before calling an external function.
PiperOrigin-RevId: 267602693
|
|
|
|
| |
PiperOrigin-RevId: 267548530
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- turn canonicalizeMapAndOperands into a template that works on both
sets and maps, and use it to introduce a utility to canonicalize an
affine integer set and its operands
- add pattern to canonicalize affine if op's.
- rename IntegerSet::getNumOperands -> IntegerSet::getNumInputs to be
consistent with AffineMap
- add missing accessors for IntegerSet
Doesn't need extensive testing since canonicalizeSetAndOperands just
reuses canonicalizeMapAndOperands' logic, and the latter is tested on
affine.apply map + operands; the new method works the same way on an
integer set + operands of an affine if op for example.
Signed-off-by: Uday Bondhugula <uday@polymagelabs.com>
Closes tensorflow/mlir#112
COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/112 from bondhugula:set-canonicalize eff72f23250b96fa7d9f5caff3877440f5de2cec
PiperOrigin-RevId: 267532876
|
|
|
|
|
|
| |
This commit defines an initial implementation of the DialectInlinerInterface for the AffineOps dialect. This change allows for affine operations to be inlined into any region that is not an affine region. Inlining into affine regions requires special handling for dimension/symbol identifiers that will be added in followups.
PiperOrigin-RevId: 267467078
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SPIR-V can explicitly declare structured control-flow constructs using merge
instructions. These explicitly declare a header block before the control
flow diverges and a merge block where control flow subsequently converges.
These blocks delimit constructs that must nest, and can only be entered
and exited in structured ways.
Instead of having a `spv.LoopMerge` op to directly model loop merge
instruction for indicating the merge and continue target, we use regions
to delimit the boundary of the loop: the merge target is the next op
following the `spv.loop` op and the continue target is the block that
has a back-edge pointing to the entry block inside the `spv.loop`'s region.
This way it's easier to discover all blocks belonging to a construct and
it plays nicer with the MLIR system.
Updated the SPIR-V.md doc.
PiperOrigin-RevId: 267431010
|