History log of /llvm-project/mlir/lib/Conversion/VectorToLLVM/ConvertVectorToLLVM.cpp (Results 151 – 175 of 232)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-11.0.0-rc2
# b98e25b6 19-Aug-2020 Benjamin Kramer <benny.kra@googlemail.com>

Make helpers static. NFC.


# 168213f9 17-Aug-2020 Alex Zinenko <zinenko@google.com>

[mlir] Move data layout from LLVMDialect to module Op attributes

Legacy implementation of the LLVM dialect in MLIR contained an instance of
llvm::Module as it was required to parse LLVM IR types. Th

[mlir] Move data layout from LLVMDialect to module Op attributes

Legacy implementation of the LLVM dialect in MLIR contained an instance of
llvm::Module as it was required to parse LLVM IR types. The access to the data
layout of this module was exposed to the users for convenience, but in practice
this layout has always been the default one obtained by parsing an empty layout
description string. Current implementation of the dialect no longer relies on
wrapping LLVM IR types, but it kept an instance of DataLayout for
compatibility. This effectively forces a single data layout to be used across
all modules in a given MLIR context, which is not desirable. Remove DataLayout
from the LLVM dialect and attach it as a module attribute instead. Since MLIR
does not yet have support for data layouts, use the LLVM DataLayout in string
form with verification inside MLIR. Introduce the layout when converting a
module to the LLVM dialect and keep the default "" description for
compatibility.

This approach should be replaced with a proper MLIR-based data layout when it
becomes available, but provides an immediate solution to compiling modules with
different layouts, e.g. for GPUs.

This removes the need for LLVMDialectImpl, which is also removed.

Depends On D85650

Reviewed By: aartbik

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

show more ...


# 0de60b55 10-Aug-2020 Thomas Raoux <thomasraoux@google.com>

[mlir] Fix mlir build break due to warning when NDEBUG is not set


# 68330ee0 10-Aug-2020 Thomas Raoux <thomasraoux@google.com>

[mlir][vector] Relax transfer_read/transfer_write restriction on memref operand

Relax the verifier for transfer_read/transfer_write operation so that it can
take a memref with a different element ty

[mlir][vector] Relax transfer_read/transfer_write restriction on memref operand

Relax the verifier for transfer_read/transfer_write operation so that it can
take a memref with a different element type than the vector being read/written.

This is based on the discourse discussion:
https://llvm.discourse.group/t/memref-cast/1514

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

show more ...


# c3c95b9c 06-Aug-2020 aartbik <ajcbik@google.com>

[mlir] [VectorOps] Improve lowering of extract_strided_slice (and friends like shape_cast)

Using a shuffle for the last recursive step in progressive lowering not only
results in much more compact I

[mlir] [VectorOps] Improve lowering of extract_strided_slice (and friends like shape_cast)

Using a shuffle for the last recursive step in progressive lowering not only
results in much more compact IR, but also more efficient code (since the
backend is no longer confused on subvector aliasing for longer vectors).

E.g. the following

%f = vector.shape_cast %v0: vector<1024xf32> to vector<32x32xf32>

yields much better x86-64 code that runs 3x faster than the original.

Reviewed By: bkramer, nicolasvasilache

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

show more ...


# 87a89e0f 06-Aug-2020 Alex Zinenko <zinenko@google.com>

[mlir] Remove llvm::LLVMContext and llvm::Module from mlir::LLVMDialectImpl

Original modeling of LLVM IR types in the MLIR LLVM dialect had been wrapping
LLVM IR types and therefore required the LLV

[mlir] Remove llvm::LLVMContext and llvm::Module from mlir::LLVMDialectImpl

Original modeling of LLVM IR types in the MLIR LLVM dialect had been wrapping
LLVM IR types and therefore required the LLVMContext in which they were created
to outlive them, which was solved by placing the LLVMContext inside the dialect
and thus having the lifetime of MLIRContext. This has led to numerous issues
caused by the lack of thread-safety of LLVMContext and the need to re-create
LLVM IR modules, obtained by translating from MLIR, in different LLVM contexts
to enable parallel compilation. Similarly, llvm::Module had been introduced to
keep track of identified structure types that could not be modeled properly.

A recent series of commits changed the modeling of LLVM IR types in the MLIR
LLVM dialect so that it no longer wraps LLVM IR types and has no dependence on
LLVMContext and changed the ownership model of the translated LLVM IR modules.
Remove LLVMContext and LLVM modules from the implementation of MLIR LLVM
dialect and clean up the remaining uses.

The only part of LLVM IR that remains necessary for the LLVM dialect is the
data layout. It should be moved from the dialect level to the module level and
replaced with an MLIR-based representation to remove the dependency of the
LLVMDialect on LLVM IR library.

Reviewed By: rriddle

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

show more ...


# 5446ec85 05-Aug-2020 Alex Zinenko <zinenko@google.com>

[mlir] take MLIRContext instead of LLVMDialect in getters of LLVMType's

Historical modeling of the LLVM dialect types had been wrapping LLVM IR types
and therefore needed access to the instance of L

[mlir] take MLIRContext instead of LLVMDialect in getters of LLVMType's

Historical modeling of the LLVM dialect types had been wrapping LLVM IR types
and therefore needed access to the instance of LLVMContext stored in the
LLVMDialect. The new modeling does not rely on that and only needs the
MLIRContext that is used for uniquing, similarly to other MLIR types. Change
LLVMType::get<Kind>Ty functions to take `MLIRContext *` instead of
`LLVMDialect *` as first argument. This brings the code base closer to
completely removing the dependence on LLVMContext from the LLVMDialect,
together with additional support for thread-safety of its use.

Depends On D85371

Reviewed By: rriddle

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

show more ...


# d3a98076 05-Aug-2020 Alex Zinenko <zinenko@google.com>

[mlir] Remove most uses of LLVMDialect::getModule

This prepares for the removal of llvm::Module and LLVMContext from the
mlir::LLVMDialect.

Reviewed By: rriddle

Differential Revision: https://revi

[mlir] Remove most uses of LLVMDialect::getModule

This prepares for the removal of llvm::Module and LLVMContext from the
mlir::LLVMDialect.

Reviewed By: rriddle

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

show more ...


# 39379916 05-Aug-2020 aartbik <ajcbik@google.com>

[mlir] [VectorOps] Add masked load/store operations to Vector dialect

The intrinsics were already supported and vector.transfer_read/write lowered
direclty into these operations. By providing them a

[mlir] [VectorOps] Add masked load/store operations to Vector dialect

The intrinsics were already supported and vector.transfer_read/write lowered
direclty into these operations. By providing them as individual ops, however,
clients can used them directly, and it opens up progressively lowering transfer
operations at higher levels (rather than direct lowering to LLVM IR as done now).

Reviewed By: bkramer

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

show more ...


# b2ab375d 05-Aug-2020 Alex Zinenko <zinenko@google.com>

[mlir] use the new stateful LLVM type translator by default

Previous type model in the LLVM dialect did not support identified structure
types properly and therefore could use stateless translations

[mlir] use the new stateful LLVM type translator by default

Previous type model in the LLVM dialect did not support identified structure
types properly and therefore could use stateless translations implemented as
free functions. The new model supports identified structs and must keep track
of the identified structure types present in the target context (LLVMContext or
MLIRContext) to avoid creating duplicate structs due to LLVM's type
auto-renaming. Expose the stateful type translation classes and use them during
translation, storing the state as part of ModuleTranslation.

Drop the test type translation mechanism that is no longer necessary and update
the tests to exercise type translation as part of the main translation flow.

Update the code in vector-to-LLVM dialect conversion that relied on stateless
translation to use the new class in a stateless manner.

Reviewed By: rriddle

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

show more ...


# e8dcf5f8 31-Jul-2020 aartbik <ajcbik@google.com>

[mlir] [VectorOps] Add expand/compress operations to Vector dialect

Introduces the expand and compress operations to the Vector dialect
(important memory operations for sparse computations), togethe

[mlir] [VectorOps] Add expand/compress operations to Vector dialect

Introduces the expand and compress operations to the Vector dialect
(important memory operations for sparse computations), together
with a first reference implementation that lowers to the LLVM IR
dialect to enable running on CPU (and other targets that support
the corresponding LLVM IR intrinsics).

Reviewed By: reidtatge

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

show more ...


# ec1f4e7c 04-Aug-2020 Alex Zinenko <zinenko@google.com>

[mlir] switch the modeling of LLVM types to use the new mechanism

A new first-party modeling for LLVM IR types in the LLVM dialect has been
developed in parallel to the existing modeling based on wr

[mlir] switch the modeling of LLVM types to use the new mechanism

A new first-party modeling for LLVM IR types in the LLVM dialect has been
developed in parallel to the existing modeling based on wrapping LLVM `Type *`
instances. It resolves the long-standing problem of modeling identified
structure types, including recursive structures, and enables future removal of
LLVMContext and related locking mechanisms from LLVMDialect.

This commit only switches the modeling by (a) renaming LLVMTypeNew to LLVMType,
(b) removing the old implementaiton of LLVMType, and (c) updating the tests. It
is intentionally minimal. Separate commits will remove the infrastructure built
for the transition and update API uses where appropriate.

Depends On D85020

Reviewed By: rriddle

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

show more ...


Revision tags: llvmorg-11.0.0-rc1
# aec38c61 23-Jul-2020 Alex Zinenko <zinenko@google.com>

[mlir] LLVMType: make getUnderlyingType private

The current modeling of LLVM IR types in MLIR is based on the LLVMType class
that wraps a raw `llvm::Type *` and delegates uniquing, printing and pars

[mlir] LLVMType: make getUnderlyingType private

The current modeling of LLVM IR types in MLIR is based on the LLVMType class
that wraps a raw `llvm::Type *` and delegates uniquing, printing and parsing to
LLVM itself. This is model makes thread-safe type manipulation hard and is
being progressively replaced with a cleaner MLIR model that replicates the type
system. In the new model, LLVMType will no longer have an underlying LLVM IR
type. Restrict access to this type in the current model in preparation for the
change.

Reviewed By: nicolasvasilache

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

show more ...


# 1485fd29 23-Jul-2020 aartbik <ajcbik@google.com>

[mlir] [VectorOps] Improve scatter/gather CPU performance

Replaced the linearized address with the proper LLVM way of
defining vector of base + indices in SIMD style. This yields
much better code. S

[mlir] [VectorOps] Improve scatter/gather CPU performance

Replaced the linearized address with the proper LLVM way of
defining vector of base + indices in SIMD style. This yields
much better code. Some prototype results with microbencmarking
sparse matrix x vector with 50% sparsity (about 2-3x faster):

LINEARIZED IMPROVED
GFLOPS sdot saxpy sdot saxpy
16x16 1.6 1.4 4.4 2.1
32x32 1.7 1.6 5.8 5.9
64x64 1.7 1.7 6.4 6.4
128x128 1.7 1.7 5.9 5.9
256x256 1.6 1.6 6.1 6.0
512x512 1.4 1.4 4.9 4.7

Reviewed By: nicolasvasilache

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

show more ...


# 19dbb230 21-Jul-2020 aartbik <ajcbik@google.com>

[mlir] [VectorOps] Add scatter/gather operations to Vector dialect

Introduces the scatter/gather operations to the Vector dialect
(important memory operations for sparse computations), together
with

[mlir] [VectorOps] Add scatter/gather operations to Vector dialect

Introduces the scatter/gather operations to the Vector dialect
(important memory operations for sparse computations), together
with a first reference implementation that lowers to the LLVM IR
dialect to enable running on CPU (and other targets that support
the corresponding LLVM IR intrinsics).

The operations can be used directly where applicable, or can be used
during progressively lowering to bring other memory operations closer to
hardware ISA support for a gather/scatter. The semantics of the operation
closely correspond to those of the corresponding llvm intrinsics.

Note that the operation allows for a dynamic index vector (which is
important for sparse computations). However, this first reference
lowering implementation "serializes" the address computation when
base + index_vector is converted to a vector of pointers. Exploring
how to use SIMD properly during these step is TBD. More general
memrefs and idiomatic versions of striding are also TBD.

Reviewed By: arpith-jacob

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

show more ...


Revision tags: llvmorg-12-init
# affbc0cd 13-Jul-2020 Nicolas Vasilache <ntv@google.com>

[mlir] Add alignment attribute to LLVM memory ops and use in vector.transfer

Summary: The native alignment may generally not be used when lowering a vector.transfer to the underlying load/store oper

[mlir] Add alignment attribute to LLVM memory ops and use in vector.transfer

Summary: The native alignment may generally not be used when lowering a vector.transfer to the underlying load/store operation. This revision fixes the unmasked load/store alignment to match that of the masked path.

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

show more ...


# 3bffe602 13-Jul-2020 Benjamin Kramer <benny.kra@googlemail.com>

[mlir][VectorOps] Lower vector.fma to llvm.fmuladd instead of llvm.fma

Summary:
These are semantically equivalent, but fmuladd allows decaying the op
into fmul+fadd if there is no fma instruction av

[mlir][VectorOps] Lower vector.fma to llvm.fmuladd instead of llvm.fma

Summary:
These are semantically equivalent, but fmuladd allows decaying the op
into fmul+fadd if there is no fma instruction available. llvm.fma lowers
to scalar calls to libm fmaf, which is a lot slower.

Reviewers: nicolasvasilache, aartbik, ftynse

Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, Kayjukh, jurahul, msifontes

Tags: #mlir

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

show more ...


# 1bfdf7c7 08-Jul-2020 aartbik <ajcbik@google.com>

[mlir] [VectorOps] Expose lowering pass options programmatically

The ConvertVectorToLLVM pass defines options that can be passed
on the command line (currently only reassociation of FP reductions
th

[mlir] [VectorOps] Expose lowering pass options programmatically

The ConvertVectorToLLVM pass defines options that can be passed
on the command line (currently only reassociation of FP reductions
through -convert-vector-to-llvm='reassociate-fp-reductions). This
CL enables setting these options programmatically (forward looking
to more options than just reassociation, as well as setting the
values from code rather than command line).

Reviewed By: nicolasvasilache

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

show more ...


Revision tags: llvmorg-10.0.1, llvmorg-10.0.1-rc4
# 9db53a18 07-Jul-2020 River Riddle <riddleriver@gmail.com>

[mlir][NFC] Remove usernames and google bug numbers from TODO comments.

These were largely leftover from when MLIR was a google project, and don't really follow LLVM guidelines.


Revision tags: llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2
# ceb1b327 26-Jun-2020 aartbik <ajcbik@google.com>

[mlir] [VectorOps] Add the ability to mark FP reductions with "reassociate" attribute

Rationale:
In general, passing "fastmath" from MLIR to LLVM backend is not supported, and even just providing su

[mlir] [VectorOps] Add the ability to mark FP reductions with "reassociate" attribute

Rationale:
In general, passing "fastmath" from MLIR to LLVM backend is not supported, and even just providing such a feature for experimentation is under debate. However, passing fine-grained fastmath related attributes on individual operations is generally accepted. This CL introduces an option to instruct the vector-to-llvm lowering phase to annotate floating-point reductions with the "reassociate" fastmath attribute, which allows the LLVM backend to use SIMD implementations for such constructs. Oher lowering passes can start using this mechanism right away in cases where reassociation is allowed.

Benefit:
For some microbenchmarks on x86-avx2, speedups over 20 were observed for longer vector (due to cleaner, spill-free and SIMD exploiting code).

Usage:
mlir-opt --convert-vector-to-llvm="reassociate-fp-reductions"

Reviewed By: ftynse, mehdi_amini

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

show more ...


# 8d67d187 18-Jun-2020 River Riddle <riddleriver@gmail.com>

[mlir][DialectConversion] Refactor how block argument types get converted

This revision removes the TypeConverter parameter passed to the apply* methods, and instead moves the responsibility of regi

[mlir][DialectConversion] Refactor how block argument types get converted

This revision removes the TypeConverter parameter passed to the apply* methods, and instead moves the responsibility of region type conversion to patterns. The types of a region can be converted using the 'convertRegionTypes' method, which acts similarly to the existing 'applySignatureConversion'. This method ensures that all blocks within, and including those moved into, a region will have the block argument types converted using the provided converter.

This has the benefit of making more of the legalization logic controlled by patterns, instead of being handled explicitly by the driver. It also opens up the possibility to support multiple type conversions at some point in the future.

This revision also adds a new utility class `FailureOr<T>` that provides a LogicalResult friendly facility for returning a failure or a valid result value.

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

show more ...


# c9eeeb38 18-Jun-2020 aartbik <ajcbik@google.com>

[mlir] [VectorOps] remove print_i1 from runtime support library

Summary:
The "i1" (viz. bool) type does not have a proper equivalent on the "C"
size. So, to avoid any ABIs issues, we simply use prin

[mlir] [VectorOps] remove print_i1 from runtime support library

Summary:
The "i1" (viz. bool) type does not have a proper equivalent on the "C"
size. So, to avoid any ABIs issues, we simply use print_i32 on an i32
value of one or zero for true and false. This has the added advantage
that one less function needs to be implemented when porting the runtime
support library.

Reviewers: ftynse, bkramer, nicolasvasilache

Reviewed By: ftynse

Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, jurahul, msifontes

Tags: #mlir

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

show more ...


# 2d2c73c5 15-Jun-2020 Jacques Pienaar <jpienaar@google.com>

[mlir] Remove OperandAdaptor

Use ::Adaptor alias instead uniformly. Makes the naming more consistent as
adaptor can refer to attributes now too.

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

[mlir] Remove OperandAdaptor

Use ::Adaptor alias instead uniformly. Makes the naming more consistent as
adaptor can refer to attributes now too.

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

show more ...


# 5f9e0466 28-May-2020 Nicolas Vasilache <ntv@google.com>

[mlir][Vector] Fix vector.transfer alignment calculation

https://reviews.llvm.org/D79246 introduces alignment propagation for vector transfer operations. Unfortunately, the alignment calculation is

[mlir][Vector] Fix vector.transfer alignment calculation

https://reviews.llvm.org/D79246 introduces alignment propagation for vector transfer operations. Unfortunately, the alignment calculation is incorrect and can result in crashes.

This revision fixes the calculation by using the natural alignment of the memref elemental type, instead of the resulting vector type.

If more alignment is desired, it can be done in 2 ways:
1. use a proper vector.type_cast to transform a memref<axbxcxdxf32> into a memref<axbxvector<cxdxf32>> giving a natural alignment of vector<cxdxf32>
2. add an alignment attribute to vector transfer operations and propagate it.

With this change the alignment in the relevant tests goes down from 128 to 4.

Lastly, a few minor cleanups are performed and the custom `isMinorIdentityMap` is deprecated.

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

show more ...


# c295a65d 27-May-2020 aartbik <ajcbik@google.com>

[mlir] [VectorOps] Add 'vector.flat_transpose' operation

Summary:
Provides a representation of the linearized LLVM instrinsic.
With tests and lowering implementation to LLVM IR dialect.
Prepares bet

[mlir] [VectorOps] Add 'vector.flat_transpose' operation

Summary:
Provides a representation of the linearized LLVM instrinsic.
With tests and lowering implementation to LLVM IR dialect.
Prepares better lowering for 2-D vector.transpose.

Reviewers: nicolasvasilache, ftynse, reidtatge, bkramer, dcaballe

Reviewed By: ftynse, dcaballe

Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, jurahul, llvm-commits

Tags: #llvm

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

show more ...


12345678910