Mainly a missing dependency caused the tests to pass if one already built
the repo, but not from a clean (or incremental) build.
--
PiperOrigin-RevId: 241852313
- Retains Quantization types and predicates.
- Retains utilities and example (testable) passes/ops.
- Retains unit tests for example passes/ops.
- Moves fixed point ops (and corresponding real ops) to FxpMathOps.
- Moves real -> fixed point pass to FxpMathOps.
- Sever the dependency on the TF dialect from Quantization. These dialects should now be open-sourcable.
--
PiperOrigin-RevId: 241825598
Currently, we only make the initial address aligned with 64-bit address but
allocate the buffer with the real size. This can cause issue when we extract
the value by the `readBits` method, which needs to read the memory in the
granularity of APINT_WORD_SIZE. In this CL, we rounded the allocation size to
the multiplies of APINT_WORD_SIZE to fix the issue.
--
PiperOrigin-RevId: 241816656
This CL adds support for lowering tensor contractions to loops declaratively.
This is done thanks to two properties of the such operations:
1. the definition of an AffineMap getLoopsToOperandRangesMap for each op which maps iteration space dimensions to ranges of the view operands, in their order of occurrence;
2. the definition of a scalar implementation for each op which creates the computation inside the loops given enclosing parallel and reduction loops,
All the other properties are derived in a generic fashion from these 2 properties and a few analyses.
A lowerToLoops transformation is added as well as a test that exercises it.
--
PiperOrigin-RevId: 241783992
This CL looses the requirement that all result patterns in a rewrite rule must
replace a result of the root op in the source pattern. Now only the last N
result pattern-generated ops are used to replace a N-result source op.
This allows to generate additional ops to aid building up final ops used to
replace the source op.
--
PiperOrigin-RevId: 241783192
Includes a draft of documentation for the quantization setup.
Given how many comments such docs have garnered in the past, I've biased towards a lightly edited first-draft so that people can argue about terminology, approach and structure without having spent too much time on it.
Note that the sections under "Uniform quantization" were cribbed nearly verbatim from internal documentation that Daniel wrote.
PiperOrigin-RevId: 241768668
OptionalAttr is just wrapping around the actual attribute; so it should just use
the actual attribute's `convertFromStorage` to read the value and wrap it around
with `Optional<>` to return. Previously it was mandating how the actual attribute
reads the value with `{0}.getValue()`.
--
PiperOrigin-RevId: 241762355
Implement conversion from the Linalg dialect to the LLVM dialect using a simple
set of DialectOpConverters and by plugging them into the dialect conversion
infrastructure. View and Range Linalg types are converted into descriptors
that store the dynamic values in an LLVM aggregate type, similarly to memrefs.
Slice operations create new descriptors based on the original descriptors and
thus remove the constraint on ViewTypes not being acceptable as function
arguments.
--
PiperOrigin-RevId: 241760189
Attributes can have default values or be optional. Checking the validity of
attributes in aggregate builder should consider that. And to be accurate,
we should check all required attributes are indeed provided in the list.
This is actually duplicating the work done by verifier. Checking the validity
of attributes should be the responsiblity of verifiers. This CL removes
the assertion for attributes in aggregate builders for the above reason.
(Assertions for operands/results are still kept since they are trivial.)
Also added more tests for aggregate builders.
--
PiperOrigin-RevId: 241746059
Some files were not built anymore internally but still referenced
from CMake. Delete them and unreference them in the CMake files.
--
PiperOrigin-RevId: 241744718
This version has been deprecated and can now be removed completely since the
last remaining user (Python bindings) migrated to declarative builders.
Several functions in lib/EDSC/Types.cpp construct core IR objects for the C
bindings. Move these functions into lib/EDSC/CoreAPIs.cpp until we decide
where they should live.
This completes the migration from the delayed-construction EDSC to Declarative
Builders.
--
PiperOrigin-RevId: 241716729
This completes the transition of Python bindings to use the declarative
builders infrastructure instead of the now-deprecated EDSC emitter
infrastructure. The relevant unit tests have been replicated using the new
functionality and the remaining end-to-end compilation tests have been updated
accordingly. The latter show an improvement in brevity and readability.
--
PiperOrigin-RevId: 241713489
The original reimplementation of EDSC as declarative builders and the
subsequent rework of Python bindings forbade to use the (true) division
operator for values of the index types without providing an alternative. Index
types only support floor and ceil division through affine maps. Expose this to
Python bindings through a `__floordiv__` function on `ValueHandle`s.
--
PiperOrigin-RevId: 241713093
This CL fixes the non-determinism across compilers in an edsc::select expression used in LowerVectorTransfers. This is achieved by factoring the expression out of the function call to ensure a deterministic order of evaluation.
Since the expression is now factored out, fewer IR is generated and the test is updated accordingly.
--
PiperOrigin-RevId: 241679962
Historically, the LLVM IR dialect has been using the generic form of MLIR
operation syntax. It is verbose and often redundant. Introduce the custom
printing and parsing for all existing operations in the LLVM IR dialect.
Update the relevant documentation and tests.
--
PiperOrigin-RevId: 241617393
This CL starts the third part of the Linalg tutorial by adding support for ops to declare how they lower themselves to other ops.
Tests are added that demonstrate matmul lowering to a loop over matvec and matvec lowering to a loop over dot.
This is part of a list of CLs that add new Transforms and Analyses to Linalg3: it iseasier to integrate in small chunks.
As part of working with the TensorContractionBase template class and in an effort to add pieces incrementally without copying code, it is easiest to define operations ahead of time in Linalg2/TensorOps.h and gradually implement them as needed. This CL performs the necessary refactoring for this to happen.
--
PiperOrigin-RevId: 241605869
The second part of the Linalg tutorial introduces:
1. the TensorContractionBase type from which all tensor contractions derive;
2. a basic set of operations DotOp, MatvecOp and MatmulOp;
3. a helper function `createFullyComposedView` that walks the producers of a SliceOp up until the root ViewOp and returns a single ViewOp;
4. programmatic examples to test MLIR construction involving these types.
This CL also refactors file organization so that:
1. clients only need to include Ops.h and Types.h while keeping independent small files separate for the purpose of the tutorial;
2. each step of the tutorial has its own linalgxxx include directory and each include explicitly states in which part of the tutorial a particular concept was introduced.
Lastly the following cleanups are applied:
1. ValueOrSliceOp is removed in favor of simpler helper function.
2. methods that walk back the chain of ops are removed from the core ops and added to a separate Analysis.
3. various additional cleanups.
--
PiperOrigin-RevId: 241555769
This CL introduces Confined as a general mechanism to compose complex attribute
constraints out of more primitive ones. It's particularly useful for automatically
generating op definitions from some external source, where we can have random
combinations of primitive constraints and it would be impractical to define a case
for each of such combination.
Two primitive attribute constraints, IntMinValue and ArrayMinCount, are added to be
used together with Confined.
--
PiperOrigin-RevId: 241435955
The first part of the Linalg tutorial introduces:
1. the RangeType and ViewType;
2. operations on those, namely RangeOp, ViewOp and SliceOp;
3. programmatic examples to test MLIR construction involving these types, ops and affine.for loops (with a mock custom op called "some_consumer").
--
PiperOrigin-RevId: 241409949
Mehdi Amini