History log of /llvm-project/mlir/lib/Conversion/VectorToLLVM/ConvertVectorToLLVM.cpp (Results 201 – 225 of 232)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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


12345678910