#
0d924700 |
| 05-Mar-2020 |
aartbik <ajcbik@google.com> |
[mlir] [VectorOps] Merge VectorReduction/VectorReductionV2 into one Op
Summary: Paying off some technical debt in VectorOps, where I introduced a special op for a fused accumulator into reduction to
[mlir] [VectorOps] Merge VectorReduction/VectorReductionV2 into one Op
Summary: Paying off some technical debt in VectorOps, where I introduced a special op for a fused accumulator into reduction to avoid some issues around printing and parsing an optional accumulator. This CL merges the two into one op again and does things the right way (still would be nice to have "assemblyFormat" for optional operands though....).
Reviewers: nicolasvasilache, andydavis1, ftynse, rriddle
Reviewed By: nicolasvasilache
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/D75699
show more ...
|
Revision tags: llvmorg-10.0.0-rc3 |
|
#
2a00ae39 |
| 25-Feb-2020 |
Tim Shen <timshen@google.com> |
[MLIR] Add LLVMConversionTarget as a customization point. NFC.
This is in preparation for the next patch D75141. The purpose is to provide a single place where LLVM dialect registers its ops as lega
[MLIR] Add LLVMConversionTarget as a customization point. NFC.
This is in preparation for the next patch D75141. The purpose is to provide a single place where LLVM dialect registers its ops as legal/illegal.
Reviewers: ftynse, mravishankar, herhut
Subscribers: jholewinski, bixia, sanjoy.google, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, csigg, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, Joonsoo, llvm-commits
Differential Revision: https://reviews.llvm.org/D75140
show more ...
|
#
69d757c0 |
| 21-Feb-2020 |
Rob Suderman <suderman@google.com> |
Move StandardOps/Ops.h to StandardOps/IR/Ops.h
Summary: NFC - Moved StandardOps/Ops.h to a StandardOps/IR dir to better match surrounding directories. This is to match other dialects, and prepare fo
Move StandardOps/Ops.h to StandardOps/IR/Ops.h
Summary: NFC - Moved StandardOps/Ops.h to a StandardOps/IR dir to better match surrounding directories. This is to match other dialects, and prepare for moving StandardOps related transforms in out for Transforms and into StandardOps/Transforms.
Differential Revision: https://reviews.llvm.org/D74940
show more ...
|
Revision tags: llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init |
|
#
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 ...
|
#
870c1fd4 |
| 18-Feb-2020 |
Alex Zinenko <zinenko@google.com> |
[mlir] NFC: rename LLVMOpLowering to ConvertToLLVMPattern
This better reflects the nature of the class and matches the current naming scheme.
Differential Revision: https://reviews.llvm.org/D74774
|
#
0f04384d |
| 18-Feb-2020 |
Alex Zinenko <zinenko@google.com> |
[mlir] NFC: Rename LLVMOpLowering::lowering to LLVMOpLowering::typeConverter
The existing name is an artifact dating back to the times when we did not have a dedicated TypeConverter infrastructure.
[mlir] NFC: Rename LLVMOpLowering::lowering to LLVMOpLowering::typeConverter
The existing name is an artifact dating back to the times when we did not have a dedicated TypeConverter infrastructure. It is also confusing with with the name of classes using it.
Differential revision: https://reviews.llvm.org/D74707
show more ...
|
#
b21c7999 |
| 13-Feb-2020 |
aartbik <ajcbik@google.com> |
[mlir] [VectorOps] Initial framework for progressively lowering vector.contract
Summary: This sets the basic framework for lowering vector.contract progressively into simpler vector.contract operati
[mlir] [VectorOps] Initial framework for progressively lowering vector.contract
Summary: This sets the basic framework for lowering vector.contract progressively into simpler vector.contract operations until a direct vector.reduction operation is reached. More details will be filled out progressively as well.
Reviewers: nicolasvasilache
Reviewed By: nicolasvasilache
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/D74520
show more ...
|
#
e83b7b99 |
| 11-Feb-2020 |
aartbik <ajcbik@google.com> |
[mlir] [VectorOps] Implement vector.reduce operation
Summary: This new operation operates on 1-D vectors and forms the bridge between vector.contract and llvm intrinsics for vector reductions.
Revi
[mlir] [VectorOps] Implement vector.reduce operation
Summary: This new operation operates on 1-D vectors and forms the bridge between vector.contract and llvm intrinsics for vector reductions.
Reviewers: nicolasvasilache, andydavis1, ftynse
Reviewed By: nicolasvasilache
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/D74370
show more ...
|
#
681f929f |
| 07-Feb-2020 |
Nicolas Vasilache <ntv@google.com> |
[mlir][VectorOps] Introduce a `vector.fma` op that works on n-D vectors and lowers to `llvm.intrin.fmuladd`
Summary: The `vector.fma` operation is portable enough across targets that we do not want
[mlir][VectorOps] Introduce a `vector.fma` op that works on n-D vectors and lowers to `llvm.intrin.fmuladd`
Summary: The `vector.fma` operation is portable enough across targets that we do not want to keep it wrapped under `vector.outerproduct` and `llvm.intrin.fmuladd`. This revision lifts the op into the vector dialect and implements the lowering to LLVM by using two patterns: 1. a pattern that lowers from n-D to (n-1)-D by unrolling when n > 2 2. a pattern that converts from 1-D to the proper LLVM representation
Reviewers: ftynse, stellaraccident, aartbik, dcaballe, jsetoain, tetuante
Reviewed By: aartbik
Subscribers: fhahn, dcaballe, merge_guards_bot, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, Joonsoo, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74075
show more ...
|
#
499ad458 |
| 07-Feb-2020 |
Nicolas Vasilache <ntv@google.com> |
[mlir][VectorOps] Expose and use llvm.intrin.fma*
Summary: This revision exposes the portable `llvm.fma` intrinsic in LLVMOps and uses it in lieu of `llvm.fmuladd` when lowering the `vector.outerpro
[mlir][VectorOps] Expose and use llvm.intrin.fma*
Summary: This revision exposes the portable `llvm.fma` intrinsic in LLVMOps and uses it in lieu of `llvm.fmuladd` when lowering the `vector.outerproduct` op to LLVM. This guarantees proper `fma` instructions will be emitted if the target ISA supports it.
`llvm.fmuladd` does not have this guarantee in its semantics, despite evidence that the proper x86 instructions are emitted.
For more details, see https://llvm.org/docs/LangRef.html#llvm-fmuladd-intrinsic.
Reviewers: ftynse, aartbik, dcaballe, fhahn
Reviewed By: aartbik
Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74219
show more ...
|
#
e52414b1 |
| 07-Feb-2020 |
aartbik <ajcbik@google.com> |
[mlir][VectorOps] Generalized vector.print to i32/i64
Summary: Lowering to LLVM IR was restricted to float/double. This CL also adds the integral values.
Reviewers: andydavis1, nicolasvasilache, ft
[mlir][VectorOps] Generalized vector.print to i32/i64
Summary: Lowering to LLVM IR was restricted to float/double. This CL also adds the integral values.
Reviewers: andydavis1, nicolasvasilache, ftynse
Reviewed By: nicolasvasilache, 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/D74179
show more ...
|
#
c8fc76a9 |
| 31-Jan-2020 |
aartbik <ajcbik@google.com> |
[mlir] [VectorOps] fixed bug in vector.insert_strided_slice lowering
Summary: Rationale: When lowering to LLVM for different rank insert (n vs k), the offset arrays needs to drop one dimension (beco
[mlir] [VectorOps] fixed bug in vector.insert_strided_slice lowering
Summary: Rationale: When lowering to LLVM for different rank insert (n vs k), the offset arrays needs to drop one dimension (becomes n-1), but the strides array needs to be preserved (remains k). With regression test. Note that this example was actually in the documentation, so extra important to do it right :-)
Reviewers: nicolasvasilache, andydavis1, ftynse
Reviewed By: nicolasvasilache, ftynse
Subscribers: Joonsoo, merge_guards_bot, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, liufengdb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73733
show more ...
|
#
459cf6e5 |
| 25-Jan-2020 |
aartbik <ajcbik@google.com> |
[mlir] [VectorOps] Lowering of vector.extract/insert_slices to LLVM IR
Summary: Uses progressive lowering to convert vector.extract_slices and vector_insert_slices to equivalent vector operations th
[mlir] [VectorOps] Lowering of vector.extract/insert_slices to LLVM IR
Summary: Uses progressive lowering to convert vector.extract_slices and vector_insert_slices to equivalent vector operations that can be subsequently lowered into LLVM.
Reviewers: nicolasvasilache, andydavis1, rriddle
Reviewed By: nicolasvasilache, rriddle
Subscribers: merge_guards_bot, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72808
show more ...
|
#
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.
|
#
90c01357 |
| 23-Jan-2020 |
Benjamin Kramer <benny.kra@googlemail.com> |
[mlir] Shrink-wrap anonymous namespaces around the classes it's supposed to enclose. NFC.
The coding standards prefer smaller anonymous namespaces with free functions just being static and in the gl
[mlir] Shrink-wrap anonymous namespaces around the classes it's supposed to enclose. NFC.
The coding standards prefer smaller anonymous namespaces with free functions just being static and in the global namespace.
show more ...
|
#
fc817b09 |
| 20-Jan-2020 |
Kazuaki Ishizaki <ishizaki@jp.ibm.com> |
[mlir] NFC: Fix trivial typos in comments
Differential Revision: https://reviews.llvm.org/D73012
|
#
df186507 |
| 14-Jan-2020 |
Benjamin Kramer <benny.kra@googlemail.com> |
Make helper functions static or move them into anonymous namespaces. NFC.
|
#
2bdf33cc |
| 11-Jan-2020 |
River Riddle <riverriddle@google.com> |
[mlir] NFC: Remove Value::operator* and Value::operator-> now that Value is properly value-typed.
Summary: These were temporary methods used to simplify the transition.
Reviewed By: antiagainst
Di
[mlir] NFC: Remove Value::operator* and Value::operator-> now that Value is properly value-typed.
Summary: These were temporary methods used to simplify the transition.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D72548
show more ...
|
#
2d515e49 |
| 09-Jan-2020 |
Nicolas Vasilache <ntv@google.com> |
[mlir][VectorOps] Implement insert_strided_slice conversion
Summary: This diff implements the progressive lowering of insert_strided_slice. Two cases appear: 1. when the source and dest vectors have
[mlir][VectorOps] Implement insert_strided_slice conversion
Summary: This diff implements the progressive lowering of insert_strided_slice. Two cases appear: 1. when the source and dest vectors have different ranks, extract the dest subvector at the proper offset and reduce to case 2. 2. when they have the same rank N: a. if the source and dest type are the same, the insertion is trivial: just forward the source b. otherwise, iterate over all N-1 D subvectors and create an extract/insert_strided_slice/insert replacement, reducing the problem to vecotrs of the same N-1 rank.
This combines properly with the other conversion patterns to lower all the way to LLVM.
Reviewers: ftynse, rriddle, AlexEichenberger, andydavis1, tetuante, nicolasvasilache
Reviewed By: andydavis1
Subscribers: merge_guards_bot, mehdi_amini, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72317
show more ...
|
#
65678d93 |
| 09-Jan-2020 |
Nicolas Vasilache <ntv@google.com> |
[mlir][VectorOps] Implement strided_slice conversion
Summary: This diff implements the progressive lowering of strided_slice to either: 1. extractelement + insertelement for the 1-D case 2. extr
[mlir][VectorOps] Implement strided_slice conversion
Summary: This diff implements the progressive lowering of strided_slice to either: 1. extractelement + insertelement for the 1-D case 2. extract + optional strided_slice + insert for the n-D case.
This combines properly with the other conversion patterns to lower all the way to LLVM.
Appropriate tests are added.
Reviewers: ftynse, rriddle, AlexEichenberger, andydavis1, tetuante
Reviewed By: andydavis1
Subscribers: merge_guards_bot, mehdi_amini, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72310
show more ...
|
#
0f0d0ed1 |
| 24-Dec-2019 |
Mehdi Amini <aminim@google.com> |
Import MLIR into the LLVM tree
|
#
e62a6956 |
| 23-Dec-2019 |
River Riddle <riverriddle@google.com> |
NFC: Replace ValuePtr with Value and remove it now that Value is value-typed.
ValuePtr was a temporary typedef during the transition to a value-typed Value.
PiperOrigin-RevId: 286945714
|
#
56222a06 |
| 23-Dec-2019 |
Mehdi Amini <aminim@google.com> |
Adjust License.txt file to use the LLVM license
PiperOrigin-RevId: 286906740
|
#
35807bc4 |
| 23-Dec-2019 |
River Riddle <riverriddle@google.com> |
NFC: Introduce new ValuePtr/ValueRef typedefs to simplify the transition to Value being value-typed.
This is an initial step to refactoring the representation of OpResult as proposed in: https://gro
NFC: Introduce new ValuePtr/ValueRef typedefs to simplify the transition to Value being value-typed.
This is an initial step to refactoring the representation of OpResult as proposed in: https://groups.google.com/a/tensorflow.org/g/mlir/c/XXzzKhqqF_0/m/v6bKb08WCgAJ
This change will make it much simpler to incrementally transition all of the existing code to use value-typed semantics.
PiperOrigin-RevId: 286844725
show more ...
|
#
1d47564a |
| 20-Dec-2019 |
Aart Bik <ajcbik@google.com> |
[VectorOps] unify vector dialect "subscripts"
PiperOrigin-RevId: 286650682
|