History log of /llvm-project/mlir/lib/Dialect/Linalg/Transforms/Promotion.cpp (Results 76 – 100 of 112)
Revision Date Author Comments
# d1866f89 18-May-2020 Pierre Oechsel <pierre.oechsel@gmail.com>

[MLIR] [Linalg] Add option to use the partial view after promotion.

For now the promoted buffer is indexed using the `full view`. The full view might be
slightly bigger than the partial view (which

[MLIR] [Linalg] Add option to use the partial view after promotion.

For now the promoted buffer is indexed using the `full view`. The full view might be
slightly bigger than the partial view (which is accounting for boundaries).
Unfortunately this does not compose easily with other transformations when multiple buffers
with shapes related to each other are involved.
Take `linalg.matmul A B C` (with A of size MxK, B of size KxN and C of size MxN) and suppose we are:
- Tiling over M by 100
- Promoting A only

This is producing a `linalg.matmul promoted_A B subview_C` where `promoted_A` is a promoted buffer
of `A` of size (100xK) and `subview_C` is a subview of size mxK where m could be smaller than 100 due
to boundaries thus leading to a possible incorrect behavior.

We propose to:
- Add a new parameter to the tiling promotion allowing to enable the use of the full tile buffer.
- By default all promoted buffers will be indexed by the partial view.

Note that this could be considered as a breaking change in comparison to the way the tiling promotion
was working.

Differential Revision: https://reviews.llvm.org/D79927

show more ...


# e0b99a5d 13-May-2020 Nicolas Vasilache <ntv@google.com>

[mlir] Add SubViewOp::getOrCreateRanges and fix folding pattern

The existing implementation of SubViewOp::getRanges relies on all
offsets/sizes/strides to be dynamic values and does not work in
comb

[mlir] Add SubViewOp::getOrCreateRanges and fix folding pattern

The existing implementation of SubViewOp::getRanges relies on all
offsets/sizes/strides to be dynamic values and does not work in
combination with canonicalization. This revision adds a
SubViewOp::getOrCreateRanges to create the missing constants in the
canonicalized case.

This allows reactivating the fused pass with staged pattern
applications.

However another issue surfaces that the SubViewOp verifier is now too
strict to allow folding. The existing folding pattern is turned into a
canonicalization pattern which rewrites memref_cast + subview into
subview + memref_cast.

The transform-patterns-matmul-to-vector can then be reactivated.

Differential Revision: https://reviews.llvm.org/D79759

show more ...


# 98eead81 10-May-2020 Sean Silva <silvasean@google.com>

[mlir][Value] Add v.getDefiningOp<OpTy>()

Summary:
This makes a common pattern of
`dyn_cast_or_null<OpTy>(v.getDefiningOp())` more concise.

Differential Revision: https://reviews.llvm.org/D79681


# 6ed61a26 11-May-2020 Nicolas Vasilache <ntv@google.com>

[mlir] Simplify and better document std.view semantics

This [discussion](https://llvm.discourse.group/t/viewop-isnt-expressive-enough/991/2) raised some concerns with ViewOp.

In particular, the han

[mlir] Simplify and better document std.view semantics

This [discussion](https://llvm.discourse.group/t/viewop-isnt-expressive-enough/991/2) raised some concerns with ViewOp.

In particular, the handling of offsets is incorrect and does not match the op description.
Note that with an elemental type change, offsets cannot be part of the type in general because sizeof(srcType) != sizeof(dstType).

Howerver, offset is a poorly chosen term for this purpose and is renamed to byte_shift.

Additionally, for all intended purposes, trying to support non-identity layouts for this op does not bring expressive power but rather increases code complexity.

This revision simplifies the existing semantics and implementation.
This simplification effort is voluntarily restrictive and acts as a stepping stone towards supporting richer semantics: treat the non-common cases as YAGNI for now and reevaluate based on concrete use cases once a round of simplification occurred.

Differential revision: https://reviews.llvm.org/D79541

show more ...


# 8dbbb223 11-May-2020 Nicolas Vasilache <ntv@google.com>

[mlir][Linalg] NFC - Refactor and simplify Promotion

Summary: This revision introduces LinalgPromotionOptions to more easily control the application of promotion patterns. It also simplifies the dif

[mlir][Linalg] NFC - Refactor and simplify Promotion

Summary: This revision introduces LinalgPromotionOptions to more easily control the application of promotion patterns. It also simplifies the different entry points into Promotion in preparation for some behavior change in subsequent revisions.

Differential Revision: https://reviews.llvm.org/D79489

show more ...


# c25b20c0 11-May-2020 Alex Zinenko <zinenko@google.com>

[mlir] NFC: Rename LoopOps dialect to SCF (Structured Control Flow)

This dialect contains various structured control flow operaitons, not only
loops, reflect this in the name. Drop the Ops suffix fo

[mlir] NFC: Rename LoopOps dialect to SCF (Structured Control Flow)

This dialect contains various structured control flow operaitons, not only
loops, reflect this in the name. Drop the Ops suffix for consistency with other
dialects.

Note that this only moves the files and changes the C++ namespace from 'loop'
to 'scf'. The visible IR prefix remains the same and will be updated
separately. The conversions will also be updated separately.

Differential Revision: https://reviews.llvm.org/D79578

show more ...


# 307cfdf5 02-May-2020 Nicolas Vasilache <ntv@google.com>

[mlir][Linalg] Mostly NFC - Refactor Linalg patterns and transformations.

Linalg transformations are currently exposed as DRRs.
Unfortunately RewriterGen does not play well with the line of work on

[mlir][Linalg] Mostly NFC - Refactor Linalg patterns and transformations.

Linalg transformations are currently exposed as DRRs.
Unfortunately RewriterGen does not play well with the line of work on named linalg ops which require variadic operands and results.
Additionally, DRR is arguably not the right abstraction to expose compositions of such patterns that don't rely on SSA use-def semantics.

This revision abandons DRRs and exposes manually written C++ patterns.

Refactorings and cleanups are performed to uniformize APIs.
This refactoring will allow replacing the currently manually specified Linalg named ops.

A collateral victim of this refactoring is the `tileAndFuse` DRR, and the one associated test, which will be revived at a later time.

Lastly, the following 2 tests do not add value and are altered:
- a dot_perm tile + interchange test does not test anything new and is removed
- a dot tile + lower to loops does not need 2-D tiling and is trimmed.

show more ...


# 367229e1 23-Apr-2020 Nicolas Vasilache <ntv@google.com>

[mlir][EDSC] Retire ValueHandle

The EDSC discussion [thread](https://llvm.discourse.group/t/evolving-builder-apis-based-on-lessons-learned-from-edsc/879) points out that ValueHandle has become an un

[mlir][EDSC] Retire ValueHandle

The EDSC discussion [thread](https://llvm.discourse.group/t/evolving-builder-apis-based-on-lessons-learned-from-edsc/879) points out that ValueHandle has become an unnecessary level of abstraction since MLIR switch from `Value *` to `Value` everywhere.

This revision removes this level of indirection.

show more ...


# 128d7275 21-Apr-2020 Pierre Oechsel <pierre.oechsel@gmail.com>

[mlir] [linalg] Specify alignment during promotion.

The buffer allocated by a promotion can be subject to other transformations afterward. For example it could be vectorized, in which case it is nee

[mlir] [linalg] Specify alignment during promotion.

The buffer allocated by a promotion can be subject to other transformations afterward. For example it could be vectorized, in which case it is needed to ensure that this buffer is memory-aligned.

Differential Revision: https://reviews.llvm.org/D78556

show more ...


# 40d139c6 16-Apr-2020 Nicolas Vasilache <ntv@google.com>

[mlir][Linalg] NFC - Split out EDSCs that require a Folder

Summary: This is an NFC cleanup in preparation for end-to-end named Linalg ops.

Differential Revision: https://reviews.llvm.org/D78331


# 92f1562f 14-Apr-2020 River Riddle <riddleriver@gmail.com>

[mlir][NFC] Remove the STLExtras.h header file now that it has been merged into LLVM.

Now that no more utilities exist within, this file can be deleted.

Differential Revision: https://reviews.llvm.

[mlir][NFC] Remove the STLExtras.h header file now that it has been merged into LLVM.

Now that no more utilities exist within, this file can be deleted.

Differential Revision: https://reviews.llvm.org/D78079

show more ...


# 3cb1f35d 08-Apr-2020 Nicolas Vasilache <ntv@google.com>

[mlir][Linalg] Use subview instead of linalg.slice in Promotion.cpp

This revision removes the reliance of Promotion on `linalg.slice` which is meant
for the rank-reducing case.

Differential Revisio

[mlir][Linalg] Use subview instead of linalg.slice in Promotion.cpp

This revision removes the reliance of Promotion on `linalg.slice` which is meant
for the rank-reducing case.

Differential Revision: https://reviews.llvm.org/D77676

show more ...


# 1834ad4a 07-Apr-2020 River Riddle <riddleriver@gmail.com>

[mlir][Pass] Update the PassGen to generate base classes instead of utilities

Summary:
This is much cleaner, and fits the same structure as many other tablegen backends. This was not done originally

[mlir][Pass] Update the PassGen to generate base classes instead of utilities

Summary:
This is much cleaner, and fits the same structure as many other tablegen backends. This was not done originally as the CRTP in the pass classes made it overly verbose/complex.

Differential Revision: https://reviews.llvm.org/D77367

show more ...


# 80aca1ea 07-Apr-2020 River Riddle <riddleriver@gmail.com>

[mlir][Pass] Remove the use of CRTP from the Pass classes

This revision removes all of the CRTP from the pass hierarchy in preparation for using the tablegen backend instead. This creates a much cle

[mlir][Pass] Remove the use of CRTP from the Pass classes

This revision removes all of the CRTP from the pass hierarchy in preparation for using the tablegen backend instead. This creates a much cleaner interface in the C++ code, and naturally fits with the rest of the infrastructure. A new utility class, PassWrapper, is added to replicate the existing behavior for passes not suitable for using the tablegen backend.

Differential Revision: https://reviews.llvm.org/D77350

show more ...


# 9a277af2 01-Apr-2020 River Riddle <riddleriver@gmail.com>

[mlir][Pass] Add support for generating pass utilities via tablegen

This revision adds support for generating utilities for passes such as options/statistics/etc. that can be inferred from the table

[mlir][Pass] Add support for generating pass utilities via tablegen

This revision adds support for generating utilities for passes such as options/statistics/etc. that can be inferred from the tablegen definition. This removes additional boilerplate from the pass, and also makes it easier to remove the reliance on the pass registry to provide certain things(e.g. the pass argument).

Differential Revision: https://reviews.llvm.org/D76659

show more ...


# e3d834a5 01-Apr-2020 River Riddle <riddleriver@gmail.com>

[mlir][Pass] Move the registration of dialect passes to tablegen

This generates a Passes.td for all of the dialects that have transformation passes. This removes the need for global registration for

[mlir][Pass] Move the registration of dialect passes to tablegen

This generates a Passes.td for all of the dialects that have transformation passes. This removes the need for global registration for all of the dialect passes.

Differential Revision: https://reviews.llvm.org/D76657

show more ...


# e9482ed1 21-Mar-2020 River Riddle <riddleriver@gmail.com>

[mlir] Move several static cl::opts to be pass options instead.

This removes the reliance on global options, and also simplifies the pass registration.

Differential Revision: https://reviews.llvm.o

[mlir] Move several static cl::opts to be pass options instead.

This removes the reliance on global options, and also simplifies the pass registration.

Differential Revision: https://reviews.llvm.org/D76552

show more ...


# e7084713 20-Mar-2020 Rob Suderman <suderman@google.com>

[mlir][NFC] Cleanup AffineOps directory structure

Summary:
Change AffineOps Dialect structure to better group both IR and Tranforms. This included extracting transforms directly related to AffineOps

[mlir][NFC] Cleanup AffineOps directory structure

Summary:
Change AffineOps Dialect structure to better group both IR and Tranforms. This included extracting transforms directly related to AffineOps. Also move AffineOps to Affine.

Differential Revision: https://reviews.llvm.org/D76161

show more ...


# 92f7e813 13-Mar-2020 Hanhan Wang <hanchung@google.com>

[mlir][Linalg] Implement padding for linalg.conv and lowering to loops.

Summary:
To enable this, two changes are needed:
1) Add an optional attribute `padding` to linalg.conv.
2) Compute if the indi

[mlir][Linalg] Implement padding for linalg.conv and lowering to loops.

Summary:
To enable this, two changes are needed:
1) Add an optional attribute `padding` to linalg.conv.
2) Compute if the indices accessing is out of bound in the loops. If so, use the
padding value `0`. Otherwise, use the value derived from load.

In the patch, the padding only works for lowering without other transformations,
e.g., tiling, fusion, etc.

Differential Revision: https://reviews.llvm.org/D75722

show more ...


# 35b68527 10-Jan-2020 Lei Zhang <antiagainst@google.com>

[mlir] Add a signedness semantics bit to IntegerType

Thus far IntegerType has been signless: a value of IntegerType does
not have a sign intrinsically and it's up to the specific operation
to decide

[mlir] Add a signedness semantics bit to IntegerType

Thus far IntegerType has been signless: a value of IntegerType does
not have a sign intrinsically and it's up to the specific operation
to decide how to interpret those bits. For example, std.addi does
two's complement arithmetic, and std.divis/std.diviu treats the first
bit as a sign.

This design choice was made some time ago when we did't have lots
of dialects and dialects were more rigid. Today we have much more
extensible infrastructure and different dialect may want different
modelling over integer signedness. So while we can say we want
signless integers in the standard dialect, we cannot dictate for
others. Requiring each dialect to model the signedness semantics
with another set of custom types is duplicating the functionality
everywhere, considering the fundamental role integer types play.

This CL extends the IntegerType with a signedness semantics bit.
This gives each dialect an option to opt in signedness semantics
if that's what they want and helps code sharing. The parser is
modified to recognize `si[1-9][0-9]*` and `ui[1-9][0-9]*` as
signed and unsigned integer types, respectively, leaving the
original `i[1-9][0-9]*` to continue to mean no indication over
signedness semantics. All existing dialects are not affected (yet)
as this is a feature to opt in.

More discussions can be found at:

https://groups.google.com/a/tensorflow.org/d/msg/mlir/XmkV8HOPWpo/7O4X0Nb_AQAJ

Differential Revision: https://reviews.llvm.org/D72533

show more ...


# 0acd7e02 17-Feb-2020 Pierre Oechsel <pierre.oechsel@gmail.com>

[mlir] Linalg: Extend promotion to non f32 buffers.

Summary:
Linalg's promotion pass was only supporting f32 buffers due to how the
zero value was build for the `fill` operation.

Moreover, `promote

[mlir] Linalg: Extend promotion to non f32 buffers.

Summary:
Linalg's promotion pass was only supporting f32 buffers due to how the
zero value was build for the `fill` operation.

Moreover, `promoteSubViewOperands` was returning a vector with one entry
per float subview while omitting integer subviews. For a program
with only integer subviews the return vector would be of size 0.
However, `promoteSubViewsOperands` would try to access a non zero
number of entries of this vector, resulting in a sefgault.

Reviewers: nicolasvasilache, ftynse

Reviewed By: ftynse

Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D74532

show more ...


# 75394e13 10-Feb-2020 Nicolas Vasilache <ntv@google.com>

[mlir][EDSC] Almost NFC - Refactor and untangle EDSC dependencies

This CL refactors EDSCs to layer them better and break unnecessary
dependencies. After this refactoring, the top-level EDSC target o

[mlir][EDSC] Almost NFC - Refactor and untangle EDSC dependencies

This CL refactors EDSCs to layer them better and break unnecessary
dependencies. After this refactoring, the top-level EDSC target only
depends on IR but not on Dialects anymore and each dialect has its
own EDSC directory.

This simplifies the layering and breaks cyclic dependencies.
In particular, the declarative builder + folder are made explicit and
are now confined to Linalg.

As the refactoring occurred, certain classes and abstractions that were not
paying for themselves have been removed.

Differential Revision: https://reviews.llvm.org/D74302

show more ...


# 74df89f6 27-Jan-2020 Kern Handa <kern.handa@gmail.com>

[NFC][mlir][linalg] Merge Utils/Intrinsics.h into EDSC/Intrinsics.h

Differential Revision: https://reviews.llvm.org/D73377


# 30857107 26-Jan-2020 Mehdi Amini <aminim@google.com>

Mass update the MLIR license header to mention "Part of the LLVM project"

This is an artifact from merging MLIR into LLVM, the file headers are
now aligned with the rest of the project.


# 7741de94 15-Jan-2020 Nicolas Vasilache <ntv@google.com>

[mlir][Linalg] NFC - Cleanup Linalg Pass locations and namespacing

Summary:
This diff moves the conversion pass declaration closer to its definition
and makes the namespacing of passes consistent wi

[mlir][Linalg] NFC - Cleanup Linalg Pass locations and namespacing

Summary:
This diff moves the conversion pass declaration closer to its definition
and makes the namespacing of passes consistent with the rest of the
infrastructure (i.e. `mlir::linalg::createXXXPass` -> `mlir::createXXXPass`).

Reviewers: ftynse, jpienaar, mehdi_amini

Subscribers: rriddle, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D72766

show more ...


12345