History log of /llvm-project-15.0.7/mlir/lib/Conversion/SCFToSPIRV/SCFToSPIRV.cpp (Results 1 – 23 of 23)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6
# 8b68da2c 17-Jun-2022 Alex Zinenko <[email protected]>

[mlir] move SCF headers to SCF/{IR,Transforms} respectively

This aligns the SCF dialect file layout with the majority of the dialects.

Reviewed By: jpienaar

Differential Revision: https://reviews.

[mlir] move SCF headers to SCF/{IR,Transforms} respectively

This aligns the SCF dialect file layout with the majority of the dialects.

Reviewed By: jpienaar

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

show more ...


Revision tags: llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3
# e084679f 19-Jan-2022 River Riddle <[email protected]>

[mlir] Make locations required when adding/creating block arguments

BlockArguments gained the ability to have locations attached a while ago, but they
have always been optional. This goes against th

[mlir] Make locations required when adding/creating block arguments

BlockArguments gained the ability to have locations attached a while ago, but they
have always been optional. This goes against the core tenant of MLIR where location
information is a requirement, so this commit updates the API to require locations.

Fixes #53279

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

show more ...


Revision tags: llvmorg-13.0.1-rc2
# e4853be2 02-Jan-2022 Mehdi Amini <[email protected]>

Apply clang-tidy fixes for performance-for-range-copy to MLIR (NFC)


# c0342a2d 20-Dec-2021 Jacques Pienaar <[email protected]>

[mlir] Switching accessors to prefixed form (NFC)

Makes eventual prefixing flag flip smaller change.


Revision tags: llvmorg-13.0.1-rc1
# 526b71e4 28-Oct-2021 Butygin <[email protected]>

[mlir] spirv: Add scf.while spirv conversion

* It works similar to scf.for coversion, but convert condition and yield ops as part of scf.whille pattern so it don't need to maintain external state

D

[mlir] spirv: Add scf.while spirv conversion

* It works similar to scf.for coversion, but convert condition and yield ops as part of scf.whille pattern so it don't need to maintain external state

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

show more ...


# 015192c6 27-Oct-2021 River Riddle <[email protected]>

[mlir:DialectConversion] Restructure how argument/target materializations get invoked

The current implementation invokes materializations
whenever an input operand does not have a mapping for the
de

[mlir:DialectConversion] Restructure how argument/target materializations get invoked

The current implementation invokes materializations
whenever an input operand does not have a mapping for the
desired type, i.e. it requires materialization at the earliest possible
point. This conflicts with goal of dialect conversion (and also the
current documentation) which states that a materialization is only
required if the materialization is supposed to persist after the
conversion process has finished.

This revision refactors this such that whenever a target
materialization "might" be necessary, we insert an
unrealized_conversion_cast to act as a temporary materialization.
This allows for deferring the invocation of the user
materialization hooks until the end of the conversion process,
where we actually have a better sense if it's actually
necessary. This has several benefits:

* In some cases a target materialization hook is no longer
necessary
When performing a full conversion, there are some situations
where a temporary materialization is necessary. Moving forward,
these users won't need to provide any target materializations,
as the temporary materializations do not require the user to
provide materialization hooks.

* getRemappedValue can now handle values that haven't been
converted yet
Before this commit, it wasn't well supported to get the remapped
value of a value that hadn't been converted yet (making it
difficult/impossible to convert multiple operations in many
situations). This commit updates getRemappedValue to properly
handle this case by inserting temporary materializations when
necessary.

Another code-health related benefit is that with this change we
can move a majority of the complexity related to materializations
to the end of the conversion process, instead of handling adhoc
while conversion is happening.

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

show more ...


# b54c724b 24-Sep-2021 River Riddle <[email protected]>

[mlir:OpConversionPattern] Add overloads for taking an Adaptor instead of ArrayRef

This has been a TODO for a long time, and it brings about many advantages (namely nice accessors, and less fragile

[mlir:OpConversionPattern] Add overloads for taking an Adaptor instead of ArrayRef

This has been a TODO for a long time, and it brings about many advantages (namely nice accessors, and less fragile code). The existing overloads that accept ArrayRef are now treated as deprecated and will be removed in a followup (after a small grace period). Most of the upstream MLIR usages have been fixed by this commit, the rest will be handled in a followup.

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

show more ...


Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4
# dc4e913b 22-Mar-2021 Chris Lattner <[email protected]>

[PatternMatch] Big mechanical rename OwningRewritePatternList -> RewritePatternSet and insert -> add. NFC

This doesn't change APIs, this just cleans up the many in-tree uses of these
names to use t

[PatternMatch] Big mechanical rename OwningRewritePatternList -> RewritePatternSet and insert -> add. NFC

This doesn't change APIs, this just cleans up the many in-tree uses of these
names to use the new preferred names. We'll keep the old names around for a
couple weeks to help transitions.

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

show more ...


# 3a506b31 20-Mar-2021 Chris Lattner <[email protected]>

Change OwningRewritePatternList to carry an MLIRContext with it.

This updates the codebase to pass the context when creating an instance of
OwningRewritePatternList, and starts removing extraneous M

Change OwningRewritePatternList to carry an MLIRContext with it.

This updates the codebase to pass the context when creating an instance of
OwningRewritePatternList, and starts removing extraneous MLIRContext
parameters. There are many many more to be removed.

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

show more ...


Revision tags: llvmorg-12.0.0-rc3
# fee90542 27-Feb-2021 Vladislav Vinogradov <[email protected]>

[mlir][ODS] Support specialized Attribute class for Enums

Add a feature to `EnumAttr` definition to generate
specialized Attribute class for the particular enumeration.

This class will inherit `Str

[mlir][ODS] Support specialized Attribute class for Enums

Add a feature to `EnumAttr` definition to generate
specialized Attribute class for the particular enumeration.

This class will inherit `StringAttr` or `IntegerAttr` and
will override `classof` and `getValue` methods.

With this class the enumeration predicate can be checked with simple
RTTI calls (`isa`, `dyn_cast`) and it will return the typed enumeration
directly instead of raw string/integer.

Based on the following discussion:
https://llvm.discourse.group/t/rfc-add-enum-attribute-decorator-class/2252

Reviewed By: rriddle

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

show more ...


# 3fb384d5 06-Mar-2021 KareemErgawy-TomTom <[email protected]>

[MLIR][SPIRV] Rename `spv.selection` to `spv.mlir.selection`.

To unify the naming scheme across all ops in the SPIR-V dialect, we are
moving from spv.camelCase to spv.CamelCase everywhere. For ops t

[MLIR][SPIRV] Rename `spv.selection` to `spv.mlir.selection`.

To unify the naming scheme across all ops in the SPIR-V dialect, we are
moving from spv.camelCase to spv.CamelCase everywhere. For ops that
don't have a SPIR-V spec counterpart, we use spv.mlir.snake_case.

Reviewed By: antiagainst

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

show more ...


# 29812a61 05-Mar-2021 KareemErgawy-TomTom <[email protected]>

[MLIR][SPIRV] Rename `spv.loop` to `spv.mlir.loop`.

To unify the naming scheme across all ops in the SPIR-V dialect,
we are moving from spv.camelCase to spv.CamelCase everywhere.

Reviewed By: antia

[MLIR][SPIRV] Rename `spv.loop` to `spv.mlir.loop`.

To unify the naming scheme across all ops in the SPIR-V dialect,
we are moving from spv.camelCase to spv.CamelCase everywhere.

Reviewed By: antiagainst

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

show more ...


Revision tags: llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1
# 7c3ae48f 09-Jan-2021 Lei Zhang <[email protected]>

[mlir][spirv] Replace SPIRVOpLowering with OpConversionPattern

The dialect conversion framework was enhanced to handle type
conversion automatically. OpConversionPattern already contains
a pointer t

[mlir][spirv] Replace SPIRVOpLowering with OpConversionPattern

The dialect conversion framework was enhanced to handle type
conversion automatically. OpConversionPattern already contains
a pointer to the TypeConverter. There is no need to duplicate it
in a separate subclass. This removes the only reason for a
SPIRVOpLowering subclass. It adapts to use core infrastructure
and simplifies the code.

Also added a utility function to OpConversionPattern for getting
TypeConverter as a certain subclass.

Reviewed By: hanchung

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

show more ...


# 930c74f1 23-Dec-2020 Lei Zhang <[email protected]>

[mlir][spirv] NFC: rename SPIR-V conversion files for consistency

This commit renames various SPIR-V related conversion files for
consistency. It drops the "Convert" prefix to various files and
fixe

[mlir][spirv] NFC: rename SPIR-V conversion files for consistency

This commit renames various SPIR-V related conversion files for
consistency. It drops the "Convert" prefix to various files and
fixes various comment headers.

Reviewed By: hanchung, ThomasRaoux

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

show more ...


Revision tags: llvmorg-11.0.1, llvmorg-11.0.1-rc2
# 01178654 17-Dec-2020 Lei Zhang <[email protected]>

[mlir][spirv] NFC: Shuffle code around to better follow convention

This commit shuffles SPIR-V code around to better follow MLIR
convention. Specifically,

* Created IR/, Transforms/, Linking/, and

[mlir][spirv] NFC: Shuffle code around to better follow convention

This commit shuffles SPIR-V code around to better follow MLIR
convention. Specifically,

* Created IR/, Transforms/, Linking/, and Utils/ subdirectories and
moved suitable code inside.
* Created SPIRVEnums.{h|cpp} for SPIR-V C/C++ enums generated from
SPIR-V spec. Previously they are cluttered inside SPIRVTypes.{h|cpp}.
* Fixed include guards in various header files (both .h and .td).
* Moved serialization tests under test/Target/SPIRV.
* Renamed TableGen backend -gen-spirv-op-utils into -gen-spirv-attr-utils
as it is only generating utility functions for attributes.

Reviewed By: mravishankar

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

show more ...


# 0bf4a82a 09-Dec-2020 Christian Sigg <[email protected]>

[mlir] Use mlir::OpState::operator->() to get to methods of mlir::Operation. This is a preparation step to remove the corresponding methods from OpState.

Reviewed By: silvas, rriddle

Differential R

[mlir] Use mlir::OpState::operator->() to get to methods of mlir::Operation. This is a preparation step to remove the corresponding methods from OpState.

Reviewed By: silvas, rriddle

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

show more ...


# c4a04059 28-Nov-2020 Christian Sigg <[email protected]>

Add `Operation* OpState::operator->()` to provide more convenient access to members of Operation.

Given that OpState already implicit converts to Operator*, this seems reasonable.

The alternative w

Add `Operation* OpState::operator->()` to provide more convenient access to members of Operation.

Given that OpState already implicit converts to Operator*, this seems reasonable.

The alternative would be to add more functions to OpState which forward to Operation.

Reviewed By: rriddle, ftynse

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

show more ...


Revision tags: llvmorg-11.0.1-rc1
# 65fcddff 19-Nov-2020 River Riddle <[email protected]>

[mlir][BuiltinDialect] Resolve comments from D91571

* Move ops to a BuiltinOps.h
* Add file comments


# 74170a3a 19-Nov-2020 Tres Popp <[email protected]>

Use rewriter in SCFToSPIRV conversion.

Additionally, clear a data structure to ensure a proper state if multiple conversion attempts are needed.

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

Use rewriter in SCFToSPIRV conversion.

Additionally, clear a data structure to ensure a proper state if multiple conversion attempts are needed.

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

show more ...


# 73ca690d 17-Nov-2020 River Riddle <[email protected]>

[mlir][NFC] Remove references to Module.h and Function.h

These includes have been deprecated in favor of BuiltinDialect.h, which contains the definitions of ModuleOp and FuncOp.

Differential Revisi

[mlir][NFC] Remove references to Module.h and Function.h

These includes have been deprecated in favor of BuiltinDialect.h, which contains the definitions of ModuleOp and FuncOp.

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

show more ...


Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3
# 6a3c69e9 26-Aug-2020 Thomas Raoux <[email protected]>

[mlir][spirv] Infer converted type of scf.for from the init value

Instead of using the TypeConverter infer the value of the alloca created based
on the init value. This will allow some ambiguous typ

[mlir][spirv] Infer converted type of scf.for from the init value

Instead of using the TypeConverter infer the value of the alloca created based
on the init value. This will allow some ambiguous types like multidimensional
vectors to be converted correctly.

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

show more ...


Revision tags: llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3
# 0670f855 02-Jul-2020 Thomas Raoux <[email protected]>

[mlir][spirv] Add support for lowering scf.for scf/if with return value

This allow lowering to support scf.for and scf.if with results. As right now
spv region operations don't have return value the

[mlir][spirv] Add support for lowering scf.for scf/if with return value

This allow lowering to support scf.for and scf.if with results. As right now
spv region operations don't have return value the results are demoted to
Function memory. We create one allocation per result right before the region
and store the yield values in it. Then we can load back the value from
allocation to be able to use the results.

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

show more ...


# fbce9855 01-Jul-2020 Thomas Raoux <[email protected]>

[mlir][NFC] Move conversion of scf to spir-v ops in their own file

Move patterns for scf to spir-v ops in their own file/folder.

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