Commit Graph

347 Commits

Author SHA1 Message Date
KareemErgawy-TomTom 4d90e460bc [MLIR][SPIRV] Rename `spv.spcConstant...` to `spv.SpcConstant...`.
To unify the naming scheme across all ops in the SPIR-V dialect, we are
moving from spv.camelCase to spv.CamelCase everywhere.

Differential Revision: https://reviews.llvm.org/D97920
2021-03-04 16:07:41 -05:00
Arpith C. Jacob 4e393350c5 [mlir] Add an AccessGroup attribute to load/store LLVM dialect ops and generate the access_group LLVM metadata.
This also includes LLVM dialect ops created from intrinsics.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D97944
2021-03-04 18:17:23 +01:00
Arpith C. Jacob 4a2930f495 [mlir] Add loop codegen options to some LLVM dialect ops.
Add a Loop Option attribute and generate llvm metadata attached to
branch instructions to control code generation.

Reviewed By: ftynse, mehdi_amini

Differential Revision: https://reviews.llvm.org/D96820
2021-03-04 09:01:57 +01:00
Weiwei Li ce2ad938ff [mlir][spirv] Define spv.GLSL.Ldexp
co-authored-by: Alan Liu <alanliu.yf@gmail.com>

Reviewed By: antiagainst

Differential Revision: https://reviews.llvm.org/D97228
2021-02-24 13:07:46 -05:00
Weiwei Li 7742620620 [mlir][spirv] Add spv.GLSL.FrexpStruct
co-authored-by: Alan Liu <alanliu.yf@gmail.com>

Reviewed By: antiagainst

Differential Revision: https://reviews.llvm.org/D96527
2021-02-17 09:02:03 -05:00
Alex Zinenko 2ab57c503e [mlir] tighten LLVM dialect verifiers to generate valid LLVM IR
Verification of the LLVM IR produced when translating various MLIR dialects was
only active when calling the translation programmatically. This has led to
several cases of invalid LLVM IR being generated that could not be caught with
textual mlir-translate tests. Add verifiers for these cases and fix the tests
in preparation for enforcing the validation of LLVM IR.

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D96774
2021-02-16 18:18:21 +01:00
Alex Zinenko 176379e0c8 [mlir] Use the interface-based translation for LLVM "intrinsic" dialects
Port the translation of five dialects that define LLVM IR intrinsics
(LLVMAVX512, LLVMArmNeon, LLVMArmSVE, NVVM, ROCDL) to the new dialect
interface-based mechanism. This allows us to remove individual translations
that were created for each of these dialects and just use one common
MLIR-to-LLVM-IR translation that potentially supports all dialects instead,
based on what is registered and including any combination of translatable
dialects. This removal was one of the main goals of the refactoring.

To support the addition of GPU-related metadata, the translation interface is
extended with the `amendOperation` function that allows the interface
implementation to post-process any translated operation with dialect attributes
from the dialect for which the interface is implemented regardless of the
operation's dialect. This is currently applied to "kernel" functions, but can
be used to construct other metadata in dialect-specific ways without
necessarily affecting operations.

Depends On D96591, D96504

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D96592
2021-02-15 14:43:07 +01:00
Alex Zinenko 4c4876c314 [mlir] Use target-specific GPU kernel attributes in lowering pipelines
Until now, the GPU translation to NVVM or ROCDL intrinsics relied on the
presence of the generic `gpu.kernel` attribute to attach additional LLVM IR
metadata to the relevant functions. This would be problematic if each dialect
were to handle the conversion of its own options, which is the intended
direction for the translation infrastructure. Introduce `nvvm.kernel` and
`rocdl.kernel` in addition to `gpu.kernel` and base translation on these new
attributes instead.

Reviewed By: herhut

Differential Revision: https://reviews.llvm.org/D96591
2021-02-12 14:09:24 +01:00
Andrew Pritchard 74c3615997 Add LLVMIR Dialect counterparts of @llvm.maximum and @llvm.minimum.
These are similar to maxnum and minnum, but they're defined to treat -0
as less than +0.  This behavior can't be expressed using float
comparisons and selects, since comparisons are defined to treat
different-signed zeros as equal.  So, the only way to communicate this
behavior into LLVM IR without defining target-specific intrinsics is to
add the corresponding ops.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D96373
2021-02-10 00:57:43 +00:00
Weiwei Li 2ef24139fc [mlir][spirv] Add support for sampled image type
co-authored-by: Alan Liu <alanliu.yf@gmail.com>

Reviewed By: antiagainst

Differential Revision: https://reviews.llvm.org/D96169
2021-02-09 14:14:07 -05:00
Denys Shabalin fa581f9438 [mlir] Add stacksave, stackrestore to llvm dialect
Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D96333
2021-02-09 15:13:16 +01:00
Alex Zinenko 2b92f21c6e [mlir] Drop deprecated syntax for LLVM dialect types
After the LLVM dialect types were ported to use built-in types, the parser kept
supporting the old syntax for LLVM dialect types to produce built-in types for
compatibility. Drop this support.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D96275
2021-02-08 19:26:21 +01:00
Alex Zinenko ba87f99168 [mlir] make vector to llvm conversion truly partial
Historically, the Vector to LLVM dialect conversion subsumed the Standard to
LLVM dialect conversion patterns. This was necessary because the conversion
infrastructure did not have sufficient support for reconciling type
conversions. This support is now available. Only keep the patterns related to
the Vector dialect in the Vector to LLVM conversion and require type casts
operations to be inserted if necessary. These casts will be removed by
following conversions if possible. Update integration tests to also run the
Standard to LLVM conversion.

There is a significant amount of test churn, which is due to (a) unnecessarily
strict tests in VectorToLLVM and (b) many patterns actually targeting Standard
dialect ops instead of LLVM dialect ops leading to tests actually exercising a
Vector->Standard->LLVM conversion. This churn is a good illustration of the
reason to make the conversion partial: now the tests only check the code in the
Vector to LLVM conversion and will not be randomly broken by changes in
Standard to LLVM conversion.

Arguably, it may be possible to extract Vector to Standard patterns into a
separate pass, but given the ongoing splitting of the Standard dialect, such
pass will be short-lived and will require further refactoring.

Depends On D95626

Reviewed By: nicolasvasilache, aartbik

Differential Revision: https://reviews.llvm.org/D95685
2021-02-04 11:33:24 +01:00
Lei Zhang e901188cf9 [mlir][spirv] Define sp.VectorShuffle
This patch adds basic op definition, parser/printer, and verifier.

Reviewed By: ThomasRaoux

Differential Revision: https://reviews.llvm.org/D95825
2021-02-02 11:08:56 -05:00
Weiwei Li 35f746c17f [mlir][spirv] Add support for OpImageType
Support OpImageType in SPIRV Dialect.

This change doesn't support operand AccessQualifier since
it is optinal and only enables under Kernel capability.

co-authored-by: Alan Liu <alanliu.yf@gmail.com>

Reviewed By: antiagainst

Differential Revision: https://reviews.llvm.org/D95580
2021-02-01 16:44:31 -05:00
Lei Zhang 75347ba1fa Revert "[mlir][spirv] Add support for OpImageType"
This reverts commit 21f1462106.
2021-02-01 15:02:34 -05:00
Lei Zhang 21f1462106 [mlir][spirv] Add support for OpImageType
Support OpImageType in SPIRV Dialect.

This change doesn't support operand AccessQualifier since
it is optinal and only enables under Kernel capability.

co-authored-by: Alan Liu <alanliu.yf@gmail.com>

Reviewed By: antiagainst

Differential Revision: https://reviews.llvm.org/D95580
2021-02-01 15:01:31 -05:00
Eric Schweitz 1d6df1fcf0 [mlir] sret and byval now require a type argument when constructed.
Fixes the LLVM code gen bugs and adds the missing tests.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D95378
2021-01-26 10:47:19 -08:00
Matthias Springer 90ebc489de Add vp2intersect to AVX512 dialect.
Adds vp2intersect to the AVX512 dialect and defines a lowering to the
LLVM dialect.

Author: Matthias Springer <springerm@google.com>

Differential Revision: https://reviews.llvm.org/D95301
2021-01-26 07:32:26 +00:00
Lei Zhang e27197f360 [mlir][spirv] Define spv.IsNan/spv.IsInf and add lowerings
spv.Ordered/spv.Unordered are meant for OpenCL Kernel capability.
For Vulkan Shader capability, we should use spv.IsNan to check
whether a number is NaN.

Add a new pattern for converting `std.cmpf ord|uno` to spv.IsNan
and bumped the pattern converting to spv.Ordered/spv.Unordered
to a higher benefit. The SPIR-V target environment will properly
select between these two patterns.

Reviewed By: mravishankar

Differential Revision: https://reviews.llvm.org/D95237
2021-01-22 13:09:33 -05:00
Eugene Zhulenev cc77a2c768 [mlir] Add coro intrinsics operations to LLVM dialect
This PR only has coro intrinsics needed for the Async to LLVM lowering. Will add other intrinsics as needed in the followup PRs.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D95143
2021-01-22 10:01:45 -08:00
MaheshRavishankar 615167c9f7 [mlir]][SPIRV] Define OrderedOp and UnorderedOp and add lowerings from Standard.
Define OrderedOp and UnorderedOp instructions in SPIR-V and convert
cmpf operations with `ord` and `uno` tag to these instructions
respectively.

Differential Revision: https://reviews.llvm.org/D95098
2021-01-21 07:56:44 -08:00
Lei Zhang 3a56a96664 [mlir][spirv] Define spv.GLSL.Fma and add lowerings
Also changes some rewriter.create + rewriter.replaceOp calls
into rewriter.replaceOpWithNewOp calls.

Reviewed By: hanchung

Differential Revision: https://reviews.llvm.org/D94965
2021-01-19 09:14:21 -05:00
Valentin Clement cf0173de69 [mlir] Add better support for f80 and f128
Add builtin f80 and f128 following @schweitz proposition
https://llvm.discourse.group/t/rfc-adding-better-support-for-higher-precision-floating-point/2526/5

Reviewed By: ftynse, rriddle

Differential Revision: https://reviews.llvm.org/D94737
2021-01-15 10:29:48 -05:00
River Riddle 93592b726c [mlir][OpFormatGen] Format enum attribute cases as keywords when possible
In the overwhelmingly common case, enum attribute case strings represent valid identifiers in MLIR syntax. This revision updates the format generator to format as a keyword in these cases, removing the need to wrap values in a string. The parser still retains the ability to parse the string form, but the printer will use the keyword form when applicable.

Differential Revision: https://reviews.llvm.org/D94575
2021-01-14 11:35:49 -08:00
Lei Zhang 2f7ec77e3c [mlir][spirv] NFC: place ops in the proper file for their categories
This commit moves dangling ops in the main ops.td file to the proper
file matching their categories. This makes ops.td as purely including
all category files.

Differential Revision: https://reviews.llvm.org/D94413
2021-01-12 10:19:37 -05:00
Alex Zinenko bd30a796fc [mlir] use built-in vector types instead of LLVM dialect types when possible
Continue the convergence between LLVM dialect and built-in types by using the
built-in vector type whenever possible, that is for fixed vectors of built-in
integers and built-in floats. LLVM dialect vector type is still in use for
pointers, less frequent floating point types that do not have a built-in
equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class
has been removed in favor of free functions capable of inspecting both built-in
and LLVM dialect vector types: `LLVM::getVectorElementType`,
`LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is
necessary to design an implemented the extensions to built-in types so as to
remove the `LLVMFixedVectorType` entirely.

Note that the default output format for the built-in vectors does not have
whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the
LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This
required changing the FileCheck patterns in several tests.

Reviewed By: mehdi_amini, silvas

Differential Revision: https://reviews.llvm.org/D94405
2021-01-12 10:04:28 +01:00
ergawy a40767ec88 [MLIR][SPIRV] Add (de-)serialization support for SpecConstantOpeation.
This commit adds support for (de-)serializing SpecConstantOpeation. One
thing worth noting is that during deserialization, we assign a fake ID to
enclosed ops inside SpecConstantOpeation. We need to do this in order
for deserialization logic to properly update ID to value map and to
later reference the created value from the sibling 'spv::YieldOp'.

Reviewed By: antiagainst

Differential Revision: https://reviews.llvm.org/D93591
2021-01-11 07:37:50 +01:00
Alex Zinenko dd5165a920 [mlir] replace LLVM dialect float types with built-ins
Continue the convergence between LLVM dialect and built-in types by replacing
the bfloat, half, float and double LLVM dialect types with their built-in
counterparts. At the API level, this is a direct replacement. At the syntax
level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively,
to be compatible with the built-in type syntax. The old keywords can still be
parsed but produce a deprecation warning and will be eventually removed.

Depends On D94178

Reviewed By: mehdi_amini, silvas, antiagainst

Differential Revision: https://reviews.llvm.org/D94179
2021-01-08 17:38:12 +01:00
Kiran Chandramohan 268ff38a71 [MLIR][OpenMP] Attribute to include WsLoop upperbound
This patch adds an attribute `inclusive` which if present causes
the upperbound to be included in the loop iteration interval.

Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D94235
2021-01-08 14:42:18 +00:00
Eric Schweitz 70b841ac31 [mlir] Adds argument attributes for using LLVM's sret and byval attributes
to the conversion of LLVM IR dialect. These attributes are used in FIR to
support the lowering of Fortran using target-specific calling conventions.

Add roundtrip tests.

Add changes per review comments/concerns.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D94052
2021-01-07 12:52:14 -08:00
Alex Zinenko 2230bf99c7 [mlir] replace LLVMIntegerType with built-in integer type
The LLVM dialect type system has been closed until now, i.e. did not support
types from other dialects inside containers. While this has had obvious
benefits of deriving from a common base class, it has led to some simple types
being almost identical with the built-in types, namely integer and floating
point types. This in turn has led to a lot of larger-scale complexity: simple
types must still be converted, numerous operations that correspond to LLVM IR
intrinsics are replicated to produce versions operating on either LLVM dialect
or built-in types leading to quasi-duplicate dialects, lowering to the LLVM
dialect is essentially required to be one-shot because of type conversion, etc.
In this light, it is reasonable to trade off some local complexity in the
internal implementation of LLVM dialect types for removing larger-scale system
complexity. Previous commits to the LLVM dialect type system have adapted the
API to support types from other dialects.

Replace LLVMIntegerType with the built-in IntegerType plus additional checks
that such types are signless (these are isolated in a utility function that
replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility
to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice.

Reviewed By: mehdi_amini, silvas, antiagainst

Differential Revision: https://reviews.llvm.org/D94178
2021-01-07 19:48:31 +01:00
Eric Schweitz bd78f4e932 [mlir] revert 82f5ee3c3e 2021-01-07 09:38:21 -08:00
Eric Schweitz 82f5ee3c3e Adds argument attributes for using LLVM's sret and byval attributes to
the conversion of LLVM IR dialect. These attributes are used in FIR to
support the lowering of Fortran using target-specific calling
conventions.

Add roundtrip tests. Add changes per review comments/concerns.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D94052
2021-01-07 09:03:16 -08:00
Ivan Butygin c1d58c2b00 [mlir] Add fastmath flags support to some LLVM dialect ops
Add fastmath enum, attributes to some llvm dialect ops, `FastmathFlagsInterface` op interface, and `translateModuleToLLVMIR` support.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D92485
2021-01-07 14:00:09 +01:00
Alex Zinenko 32a884c9c5 [mlir] Add translation of omp.wsloop to LLVM IR
Introduce a translation of OpenMP workshare loop construct to LLVM IR. This is
a minimalist version to enable the pipeline and currently only supports static
loop schedule (default in the specification) on non-collapsed loops. Other
features will be added on per-need basis.

Reviewed By: kiranchandramohan

Differential Revision: https://reviews.llvm.org/D92055
2020-12-23 11:52:28 +01:00
Brian Gesiak 14f24155a5 [mlir][LLVMIR] Add 'llvm.switch' op
The LLVM IR 'switch' instruction allows control flow to be transferred
to one of any number of branches depending on an integer control value,
or a default value if the control does not match any branch values. This patch
adds `llvm.switch` to the MLIR LLVMIR dialect, as well as translation routines
for lowering it to LLVM IR.

To store a variable number of operands for a variable number of branch
destinations, the new op makes use of the `AttrSizedOperandSegments`
trait. It stores its default branch operands as one segment, and all
remaining case branches' operands as another. It also stores pairs of
begin and end offset values to delineate the sub-range of each case branch's
operands. There's probably a better way to implement this, since the
offset computation complicates several parts of the op definition. This is the
approach I settled on because in doing so I was able to delegate to the default
op builder member functions. However, it may be preferable to instead specify
`skipDefaultBuilders` in the op's ODS, or use a completely separate
approach; feedback is welcome!

Another contentious part of this patch may be the custom printer and
parser functions for the op. Ideally I would have liked the MLIR to be
printed in this way:

```
llvm.switch %0, ^bb1(%1 : !llvm.i32) [
  1: ^bb2,
  2: ^bb3(%2, %3 : !llvm.i32, !llvm.i32)
]
```

The above would resemble how LLVM IR is formatted for the 'switch'
instruction. But I found it difficult to print and parse something like
this, whether I used the declarative assembly format or custom functions.
I also was not sure a multi-line format would be welcome -- it seems
like most MLIR ops do not use newlines. Again, I'd be happy to hear any
feedback here as well, or on any other aspect of the patch.

Differential Revision: https://reviews.llvm.org/D93005
2020-12-17 14:11:21 -05:00
Lei Zhang 0117865412 [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
2020-12-17 11:03:26 -05:00
Javier Setoain aece4e2793 [mlir][ArmSVE][RFC] Add an ArmSVE dialect
This revision starts an Arm-specific ArmSVE dialect discussed in the discourse RFC thread:

https://llvm.discourse.group/t/rfc-vector-dialects-neon-and-sve/2284

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D92172
2020-12-14 21:35:01 +00:00
Nicolas Vasilache 7310501f74 [mlir][ArmNeon][RFC] Add a Neon dialect
This revision starts an Arm-specific ArmNeon dialect discussed in the [discourse RFC thread](https://llvm.discourse.group/t/rfc-vector-dialects-neon-and-sve/2284).

Differential Revision: https://reviews.llvm.org/D92171
2020-12-11 13:49:40 +00:00
Sourabh Singh Tomar c11d868a39 [MLIR,OpenMP] Added support for lowering MasterOp to LLVMIR
Some Ops in OMP dialect have regions associated with them i.e
`ParallelOp` `MasterOp`. Lowering of these regions involves interfacing
with `OMPIRBuilder` using callbacks, yet there still exist opportunities
for sharing common code in between.

This patch factors out common code into a separate function and adds
support for lowering `MasterOp` using that. Lowering of `ParallelOp` is
also modified appropriately.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D87247
2020-12-07 10:23:54 +05:30
River Riddle 7924fb34f3 [mlir][OpFormatGen] Add support for optional enum attributes
The check for formatting enum attributes was missing a call to get the base attribute, which is necessary to strip off the top-level OptionalAttr<> wrapper.

Differential Revision: https://reviews.llvm.org/D92713
2020-12-04 21:00:44 -08:00
Nicolas Vasilache 047400ed82 [mlir][LLVMIR] Add support for InlineAsmOp
The InlineAsmOp mirrors the underlying LLVM semantics with a notable
exception: the embedded `asm_string` is not allowed to define or reference
any symbol or any global variable: only the operands of the op may be read,
written, or referenced.
Attempting to define or reference any symbol or any global behavior is
considered undefined behavior at this time.

The asm dialect syntax is currently specified with an integer (0 [default] for the "att dialect", 1 for the intel dialect) to circumvent the ODS limitation on string enums.

Translation to LLVM is provided and raises the fact that the asm constraints string must be well-formed with respect to in/out operands. No check is performed on the asm_string.

An InlineAsm instruction in LLVM is a special call operation to a function that is constructed on the fly.
It does not fit the current model of MLIR calls with symbols.
As a consequence, the current implementation constructs the function type in ModuleTranslation.cpp.
This should be refactored in the future.

The mlir-cpu-runner is augmented with the global initialization of the X86 asm parser to allow proper execution in JIT mode. Previously, only the X86 asm printer was initialized.

Differential revision: https://reviews.llvm.org/D92166
2020-11-30 08:32:02 +00:00
Nicolas Vasilache 5dd5a08363 [mlir] Let ModuleTranslate propagate LLVM triple
This adds LLVM triple propagation and updates the test that did not check it properly.

Differential Revision: https://reviews.llvm.org/D92182
2020-11-27 08:01:44 +00:00
Ji Kim 58ce4a8b11 [mlir][TableGen] Support intrinsics with multiple returns and overloaded operands.
For intrinsics with multiple returns where one or more operands are overloaded, the overloaded type is inferred from the corresponding field of the resulting struct, instead of accessing the result directly.

As such, the hasResult parameter of LLVM_IntrOpBase (and derived classes) is replaced with numResults. TableGen for intrinsics also updated to populate this field with the total number of results.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D91680
2020-11-19 09:59:42 +01:00
Scott Todd c9e9cc3fe7 [MLIR] Allow setting "CodeView" flag in LLVMIR translation on MSVC.
Reviewed By: ftynse, mehdi_amini

Differential Revision: https://reviews.llvm.org/D91365
2020-11-13 17:31:18 +01:00
Arthur Eubanks 5c31b8b94f Revert "Use uint64_t for branch weights instead of uint32_t"
This reverts commit 10f2a0d662.

More uint64_t overflows.
2020-10-31 00:25:32 -07:00
Arthur Eubanks 10f2a0d662 Use uint64_t for branch weights instead of uint32_t
CallInst::updateProfWeight() creates branch_weights with i64 instead of i32.
To be more consistent everywhere and remove lots of casts from uint64_t
to uint32_t, use i64 for branch_weights.

Reviewed By: davidxl

Differential Revision: https://reviews.llvm.org/D88609
2020-10-30 10:03:46 -07:00
Arthur Eubanks 213f6dd715 Revert "Updating llvm.mlir test to match recent IR change"
This reverts commit 0fc1aa22ee.
2020-10-27 08:35:18 -07:00
Kiran Chandramohan 0fc1aa22ee Updating llvm.mlir test to match recent IR change
Recent change updated branch weights to use i64 instead of i32.
Updating llvm.mlir test to match this change.
https://reviews.llvm.org/D88609
2020-10-27 08:17:49 +00:00
Kiran Chandramohan a71a0d6d21 [OpenMP][MLIR] Fix for nested parallel regions
Usage of nested parallel regions were not working correctly and leading
to assertion failures. Fix contains the following changes,
1) Don't set the insertion point in the body callback.
2) Save the continuation IP in a stack and set the branch to
continuationIP at the terminator.

Reviewed By: SouraVX, jdoerfert, ftynse

Differential Revision: https://reviews.llvm.org/D88720
2020-10-19 08:45:50 +01:00
Amara Emerson c1247f0e74 [mlir] Fix build after 322d0afd87 due to change in intrinsic overloads.
I'd forgottent to run the mlir tests after removing the scalar input overload
on the fadd/fmul reductions. This is a quick fix for the mlir bot.
2020-10-07 11:21:11 -07:00
Amara Emerson 322d0afd87 [llvm][mlir] Promote the experimental reduction intrinsics to be first class intrinsics.
This change renames the intrinsics to not have "experimental" in the name.

The autoupgrader will handle legacy intrinsics.

Relevant ML thread: http://lists.llvm.org/pipermail/llvm-dev/2020-April/140729.html

Differential Revision: https://reviews.llvm.org/D88787
2020-10-07 10:36:44 -07:00
Tim Shen f0506e4923 [MLIR] Avoid adding debuginfo for a function if it contains calls that has no debug info.
Also add a verifier pass to ExecutionEngine.

It's hard to come up with a test case, since mlir-opt always add location info after parsing it (?)

Differential Revision: https://reviews.llvm.org/D88135
2020-09-29 13:51:56 -07:00
Kiran Kumar T P f3ead88e9c [MLIR][OpenMP] Removed the ambiguity in flush op assembly syntax
Summary:
========
Bugzilla Ticket No: Bug 46884 [https://bugs.llvm.org/show_bug.cgi?id=46884]

Flush op assembly syntax was ambiguous:

Consider the below test case:
flush operation is not having any arguments.
But the next statement token i.e "%2" is read as the argument for flush operation and then translator issues an error.
***************************************************************
$ cat -n flush.mlir
     1  llvm.func @_QQmain(%arg0: !llvm.i32) {
     2    %0 = llvm.mlir.constant(1 : i64) : !llvm.i64
     3    %1 = llvm.alloca %0 x !llvm.i32 {in_type = i32, name = "a"} : (!llvm.i64) -> !llvm.ptr<i32>
     4    omp.flush
     5    %2 = llvm.load %1 : !llvm.ptr<i32>
     6    llvm.return
     7  }

$ mlir-translate -mlir-to-llvmir flush.mlir
flush.mlir:5:6: error: expected ':'
  %2 = llvm.load %1 : !llvm.ptr<i32>
     ^
***************************************************************

Solution:
=========
Introduced begin ( `(` ) and end token ( `)` ) to determince the begin and end of variadic arguments.

The patch includes code changes and testcase modifications.

Reviewed By: Valentin Clement, Mehdi AMINI

Differential Revision: https://reviews.llvm.org/D88376
2020-09-29 09:41:46 +05:30
Kazuaki Ishizaki a23d055912 [mlir] NFC: fix trivial typo under test and tools
Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D86648
2020-08-27 15:37:42 +09:00
Juneyoung Lee 0c55889d80 [IR] Remove noundef from masked store/load/gather/scatter's pointer operands
As discussed in D86576, noundef attribute is removed from masked store/load/gather/scatter's
pointer operands.

Reviewed By: efriedma

Differential Revision: https://reviews.llvm.org/D86656
2020-08-27 06:41:43 +09:00
Juneyoung Lee 684b43c0cf [IR] Add NoUndef attribute to Intrinsics.td
This patch adds NoUndef to Intrinsics.td.
The attribute is attached to llvm.assume's operand, because llvm.assume(undef)
is UB.
It is attached to pointer operands of several memory accessing intrinsics
as well.

This change makes ValueTracking::getGuaranteedNonPoisonOps' intrinsic check
unnecessary, so it is removed.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D86576
2020-08-27 02:54:48 +09:00
aartbik 84fdc33f47 [mlir] [LLVMIR] Add get active lane mask intrinsic
Provides fast, generic way of setting a mask up to a certain
point. Potential use cases that may benefit are create_mask
and transfer_read/write operations in the vector dialect.

Reviewed By: bkramer

Differential Revision: https://reviews.llvm.org/D86501
2020-08-25 12:19:17 -07:00
Alex Zinenko 9c4825ce28 [mlir] do not use llvm.cmpxchg with floats
According to the LLVM Language Reference, 'cmpxchg' accepts integer or pointer
types. Several MLIR tests were using it with floats as it appears possible to
programmatically construct and print such an instruction, but it cannot be
parsed back. Use integers instead.

Depends On D85899

Reviewed By: flaub, rriddle

Differential Revision: https://reviews.llvm.org/D85900
2020-08-17 15:44:23 +02:00
Alex Zinenko 168213f91c [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
2020-08-17 15:12:36 +02:00
Kiran Chandramohan e6c5e6efd0 [MLIR,OpenMP] Lowering of parallel operation: proc_bind clause 2/n
This patch adds the translation of the proc_bind clause in a
parallel operation.

The values that can be specified for the proc_bind clause are
specified in the OMP.td tablegen file in the llvm/Frontend/OpenMP
directory. From this single source of truth enumeration for
proc_bind is generated in llvm and mlir (used in specification of
the parallel Operation in the OpenMP dialect). A function to return
the enum value from the string representation is also generated.
A new header file (DirectiveEmitter.h) containing definitions of
classes directive, clause, clauseval etc is created so that it can
be used in mlir as well.

Reviewers: clementval, jdoerfert, DavidTruby

Differential Revision: https://reviews.llvm.org/D84347
2020-08-12 08:03:13 +01:00
Kiran Chandramohan 660832c4e7 [OpenMP,MLIR] Translation of parallel operation: num_threads, if clauses 3/n
This simple patch translates the num_threads and if clauses of the parallel
operation. Also includes test cases.
A minor change was made to parsing of the if clause to parse AnyType and
return the parsed type. Updates to test cases also.

Reviewed by: SouraVX
Differential Revision: https://reviews.llvm.org/D84798
2020-08-07 20:54:24 +00:00
Alex Zinenko b2ab375d1f [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
2020-08-06 00:36:33 +02:00
Alex Zinenko 4e491570b5 [mlir] Remove LLVMTypeTestDialect
This dialect was introduced during the bring-up of the new LLVM dialect type
system for testing purposes. The main LLVM dialect now uses the new type system
and the test dialect is no longer necessary, so remove it.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D85224
2020-08-05 14:39:36 +02:00
aartbik e8dcf5f87d [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
2020-08-04 12:00:42 -07:00
Alex Zinenko ec1f4e7c3b [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
2020-08-04 14:29:25 +02:00
Alex Zinenko d4fbbab2e4 [mlir] translate types between MLIR LLVM dialect and LLVM IR
With new LLVM dialect type modeling, the dialect types no longer wrap LLVM IR
types. Therefore, they need to be translated to and from LLVM IR during export
and import. Introduce the relevant functionality for translating types. It is
currently exercised by an ad-hoc type translation roundtripping test that will
be subsumed by the actual translation test when the type system transition is
complete.

Depends On D84339

Reviewed By: herhut

Differential Revision: https://reviews.llvm.org/D85019
2020-08-04 13:42:43 +02:00
George Mitenkov 1880532036 [MLIR][SPIRVToLLVM] Conversion of GLSL ops to LLVM intrinsics
This patch introduces new intrinsics in LLVM dialect:
-  `llvm.intr.floor`
-  `llvm.intr.maxnum`
-  `llvm.intr.minnum`
-  `llvm.intr.smax`
-  `llvm.intr.smin`
These intrinsics correspond to SPIR-V ops from GLSL
extended instruction set (`spv.GLSL.Floor`, `spv.GLSL.FMax`,
`spv.GLSL.FMin`,  `spv.GLSL.SMax` and `spv.GLSL.SMin`
respectively). Also conversion patterns for them were added.

Reviewed By: antiagainst

Differential Revision: https://reviews.llvm.org/D84661
2020-07-30 11:22:44 +03:00
George Mitenkov 36618274f3 [MLIR][LLVMDialect] Added volatile and nontemporal attributes to load/store
This patch introduces 2 new optional attributes to `llvm.load`
and `llvm.store` ops: `volatile` and `nontemporal`. These attributes
are translated into proper LLVM as a `volatile` marker and a metadata node
respectively. They are also helpful with SPIR-V to LLVM dialect conversion
since they are the mappings for `Volatile` and `NonTemporal` Memory Operands.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D84396
2020-07-27 10:55:56 +03:00
George Mitenkov 99d03f0391 [MLIR][LLVMDialect] Added branch weights attribute to CondBrOp
This patch introduces branch weights metadata to `llvm.cond_br` op in
LLVM Dialect. It is modelled as optional `ElementsAttr`, for example:
```
llvm.cond_br %cond weights(dense<[1, 3]> : vector<2xi32>), ^bb1, ^bb2
```
When exporting to proper LLVM, this attribute is transformed into metadata
node. The test for metadata creation is added to `../Target/llvmir.mlir`.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D83658
2020-07-24 10:11:13 +03:00
aartbik 19dbb230a2 [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
2020-07-21 10:57:40 -07:00
Alex Zinenko ebbdecdd57 [mlir] Support translating function linkage between MLIR and LLVM IR
Linkage support is already present in the LLVM dialect, and is being translated
for globals other than functions. Translation support has been missing for
functions because their conversion goes through a different code path than
other globals.

Differential Revision: https://reviews.llvm.org/D84149
2020-07-20 14:04:31 +02:00
Florian Hahn c872e809d1 [Matrix] Only pass vector arg as overloaded type in MatrixBuilder.
In 2b3c505, the pointer arguments for the matrix load and store
intrinsics was changed to always be the element type of the vector
argument.

This patch updates the MatrixBuilder to not add the pointer type to the
overloaded types and adjusts the clang/mlir tests.

This should fix a few build failures on GreenDragon, including
 http://green.lab.llvm.org/green/job/test-suite-verify-machineinstrs-x86_64-O0-g/7891/
2020-07-15 10:42:24 +01:00
Kiran Chandramohan d9067dca7b Lowering of OpenMP Parallel operation to LLVM IR 1/n
This patch introduces lowering of the OpenMP parallel operation to LLVM
IR using the OpenMPIRBuilder.

Functions topologicalSort and connectPhiNodes are generalised so that
they work with operations also. connectPhiNodes is also made static.

Lowering works for a parallel region with multiple blocks. Clauses and
arguments of the OpenMP operation are not handled.

Reviewed By: rriddle, anchu-rajendran

Differential Revision: https://reviews.llvm.org/D81660
2020-07-13 23:55:45 +01:00
Sean Silva a084b94f11 [mlir] Convert function signatures before converting globals
Summary: This allows global initializers to reference functions.

Differential Revision: https://reviews.llvm.org/D83266
2020-07-07 10:40:02 -07:00
Alex Zinenko cba733edf5 [mlir] LLVM dialect: use addressof instead of constant to create function pointers
`llvm.mlir.constant` was originally introduced as an LLVM dialect counterpart
to `std.constant`. As such, it was supporting "function pointer" constants
derived from the symbol name. This is different from `std.constant` that allows
for creation of a "function" constant since MLIR, unlike LLVM IR, supports
this. Later, `llvm.mlir.addressof` was introduced as an Op that obtains a
constant pointer to a global in the LLVM dialect. It naturally extends to
functions (in LLVM IR, functions are globals) and should be used for defining
"function pointer" values instead.

Fixes PR46344.

Differential Revision: https://reviews.llvm.org/D82667
2020-06-29 12:21:33 +02:00
aartbik ceb1b327b5 [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
2020-06-26 11:03:14 -07:00
Alex Zinenko 6323065fd6 [mlir] support returning unranked memrefs
Initially, unranked memref descriptors in the LLVM dialect were designed only
to be passed into functions. An assertion was guarding against returning
unranked memrefs from functions in the standard-to-LLVM conversion. This is
insufficient for functions that wish to return an unranked memref such that the
caller does not know the rank in advance, and hence cannot allocate the
descriptor and pass it in as an argument.

Introduce a calling convention for returning unranked memref descriptors as
follows. An unranked memref descriptor always points to a ranked memref
descriptor stored on stack of the current function. When an unranked memref
descriptor is returned from a function, the ranked memref descriptor it points
to is copied to dynamically allocated memory, the ownership of which is
transferred to the caller. The caller is responsible for deallocating the
dynamically allocated memory and for copying the pointed-to ranked memref
descriptor onto its stack.

Provide default lowerings for std.return, std.call and std.indirect_call that
maintain the conversion defined above.

This convention is additionally exercised by a runtime test to guard against
memory errors.

Differential Revision: https://reviews.llvm.org/D82647
2020-06-26 15:37:37 +02:00
George Mitenkov a2edbd8170 [MLIR][LLVMDialect] Added bitreverse and ctpop intrinsics
Introduced `llvm.intr.bitreverse` and `llvm.intr.ctpop` LLVM bit
intrinsics to LLVM dialect. These intrinsics help with SPIR-V to
LLVM conversion, allowing a direct mapping from `spv.BitReverse`
and `spv.BitCount` respectively. Tests are added to `roundtrip.mlir`
and `llvm-intrinsics.mlir`.

Differential Revision: https://reviews.llvm.org/D82285
2020-06-23 14:25:35 -04:00
Stephan Herhut 2416e28c25 [mlir] Add support for alignment annotations to the LLVM dialect to LLVM translation.
Summary:
With this change, a function argument attribute of the form
"llvm.align" = <int> will be translated to the corresponding align
attribute in LLVM by the ModuleConversion.

Differential Revision: https://reviews.llvm.org/D82161
2020-06-19 16:36:06 +02:00
Florian Hahn 6d18c2067e [Matrix] Update load/store intrinsics.
This patch adjust the load/store matrix intrinsics, formerly known as
llvm.matrix.columnwise.load/store, to improve the naming and allow
passing of extra information (volatile).

The patch performs the following changes:
 * Rename columnwise.load/store to column.major.load/store. This is more
   expressive and also more in line with the naming in Clang.
 * Changes the stride arguments from i32 to i64. The stride can be
   larger than i32 and this makes things more uniform with the way
   things are handled in Clang.
 * A new boolean argument is added to indicate whether the load/store
   is volatile. The lowering respects that when emitting vector
   load/store instructions
 * MatrixBuilder is updated to require both Alignment and IsVolatile
   arguments, which are passed through to the generated intrinsic. The
   alignment is set using the `align` attribute.

The changes are grouped together in a single patch, to have a single
commit that breaks the compatibility. We probably should be fine with
updating the intrinsics, as we did not yet officially support them in
the last stable release. If there are any concerns, we can add
auto-upgrade rules for the columnwise intrinsics though.

Reviewers: anemet, Gerolf, hfinkel, andrew.w.kaylor, LuoYuanke, nicolasvasilache, rjmccall, ftynse

Reviewed By: anemet, nicolasvasilache

Differential Revision: https://reviews.llvm.org/D81472
2020-06-18 09:44:52 +01:00
Mehdi Amini bd970ef7c6 Fix MLIR test after 1d33c09f220e: matrix intrinsics have "nocapture" on some arguments (NFC) 2020-06-15 22:57:04 +00:00
Diego Caballero 7d59f49bda [mlir] Fix representation of BF16 constants
This patch is a follow-up on https://reviews.llvm.org/D81127

BF16 constants were represented as 64-bit floating point values due to the lack
of support for BF16 in APFloat. APFloat was recently extended to support
BF16 so this patch is fixing the BF16 constant representation to be 16-bit.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D81218
2020-06-05 17:43:06 -07:00
River Riddle c0cd1f1c5c [mlir] Refactor BoolAttr to be a special case of IntegerAttr
This simplifies a lot of handling of BoolAttr/IntegerAttr. For example, a lot of places currently have to handle both IntegerAttr and BoolAttr. In other places, a decision is made to pick one which can lead to surprising results for users. For example, DenseElementsAttr currently uses BoolAttr for i1 even if the user initialized it with an Array of i1 IntegerAttrs.

Differential Revision: https://reviews.llvm.org/D81047
2020-06-04 16:41:24 -07:00
George Mitenkov 7293dd5b40 Added pow intrinsic to LLVMIR dialect
Added pow intrinsic to LLVMIR dialect. Added a roundrip test for it.

Differential Revision: https://reviews.llvm.org/D80248
2020-05-25 07:57:33 -04:00
jerryyin 9c53ac08de [mlir][rocdl] Exposing buffer load/store intrinsic
Summary:
* Updated ROCDLOps tablegen
* Added parsing and printing function for new intrinsic
* Added unit tests

Reviewers: ftynse

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/D80233
2020-05-21 14:14:35 +00:00
Kiran Kumar T P fa8fc9ffcc [MLIR, OpenMP] Support for flush operation, and translating the same to LLVM IR
Summary:
This patch adds support for flush operation in OpenMP dialect and translation of this construct to LLVM IR.
The OpenMP IRBuilder is used for this translation.
The patch includes code changes and testcase modifications.

Reviewed By: ftynse, kiranchandramohan

Differential Revision: https://reviews.llvm.org/D79937
2020-05-19 17:01:25 +05:30
aartbik b1c688dbae [mlir] [VectorOps] Implement vector.create_mask lowering to LLVM IR
Summary:
First, compact implementation of lowering to LLVM IR. A bit more
challenging than the constant mask due to the dynamic indices, of course.
I like to hear if there are more efficient ways of doing this in LLVM,
but this for now at least gives us a functional reference implementation.

Reviewers: nicolasvasilache, ftynse, bkramer, reidtatge, andydavis1, mehdi_amini

Reviewed By: nicolasvasilache

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/D79954
2020-05-15 11:02:30 -07:00
Nikita Popov f89f7da999 [IR] Convert null-pointer-is-valid into an enum attribute
The "null-pointer-is-valid" attribute needs to be checked by many
pointer-related combines. To make the check more efficient, convert
it from a string into an enum attribute.

In the future, this attribute may be replaced with data layout
properties.

Differential Revision: https://reviews.llvm.org/D78862
2020-05-15 19:41:07 +02:00
aartbik fb2c4d50f1 [mlir] [VectorOps] Implement vector.constant_mask lowering to LLVM IR
Summary:
Makes this operation runnable on CPU by generating MLIR instructions
that are eventually folded into an LLVM IR constant for the mask.

Reviewers: nicolasvasilache, ftynse, reidtatge, bkramer, andydavis1

Reviewed By: nicolasvasilache, ftynse, andydavis1

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

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D79815
2020-05-12 19:44:23 -07:00
rtayl 58cb88733f [mlir][rocdl] Add xdlops intrinsics to rocdl dialect
Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir.

Reviewers: ftynse

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

Tags: #llvm #mlir

Differential Revision: https://reviews.llvm.org/D79642
2020-05-11 10:08:58 -04:00
Wen-Heng (Jack) Chung bc23c1d85e [mlir][rocdl] add rocdl.barier op.
- Add rocdl.barrier op.
- Lower gpu.barier to rocdl.barrier in -convert-gpu-to-rocdl.

Differential Revision: https://reviews.llvm.org/D79126
2020-05-04 10:35:01 +02:00
Uday Bondhugula 0a54887dac Fix MLIR test case failure caused by 89e0662dee
Fix MLIR test case failure introduced by
89e0662dee. LLVM's IR builder
now automatically sets the alignment on alloca.
2020-04-14 09:54:22 +05:30
Kiran Kumar T P 7ecee63e71 [MLIR] Support for taskwait and taskyield operations, and translating the same to LLVM IR
This patch adds support for taskwait and taskyield operations in OpenMP dialect and translation of the these constructs to LLVM IR. The OpenMP IRBuilder is used for this translation.
The patch includes code changes and a testcase modifications.

Differential Revision: https://reviews.llvm.org/D77634
2020-04-10 07:42:34 +00:00
Christian Sigg 06ddb7946b [MLIR] Add missing colon after CHECKs.
Reviewers: herhut

Reviewed By: herhut

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

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D77709
2020-04-08 11:16:06 +02:00
Alex Zinenko 0a2131b7e2 [mlir] LLVMFuncOp: provide a capability to pass attributes through to LLVM IR
Summary:
LLVM IR functions can have arbitrary attributes attached to them, some of which
affect may affect code transformations. Until we can model all attributes
consistently, provide a pass-through mechanism that forwards attributes from
the LLVMFuncOp in MLIR to LLVM IR functions during translation. This mechanism
relies on LLVM IR being able to recognize string representations of the
attributes and performs some additional checking to avoid hitting assertions
within LLVM code.

Differential Revision: https://reviews.llvm.org/D77072
2020-04-02 12:52:46 +02:00
Aaron Smith 6dab806712 [mlir] Add exp2 conversion to llvm.intr.exp2 2020-03-29 01:23:08 -07:00
Stephan Herhut ac9d742bbe [MLIR][LLVM] Make index type bitwidth configurable.
This change adds a new option to the StandardToLLVM lowering to configure
the bitwidth of the index type independently of the target architecture's
pointer size.

Differential revision: https://reviews.llvm.org/D76353
2020-03-27 12:42:54 +01:00
Nicolas Vasilache 462db62053 [mlir][AVX512] Start a primitive AVX512 dialect
The Vector Dialect [document](https://mlir.llvm.org/docs/Dialects/Vector/) discusses the vector abstractions that MLIR supports and the various tradeoffs involved.

One of the layer that is missing in OSS atm is the Hardware Vector Ops (HWV) level.

This revision proposes an AVX512-specific to add a new Dialect/Targets/AVX512 Dialect that would directly target AVX512-specific intrinsics.

Atm, we rely too much on LLVM’s peephole optimizer to do a good job from small insertelement/extractelement/shufflevector. In the future, when possible, generic abstractions such as VP intrinsics should be preferred.

The revision will allow trading off HW-specific vs generic abstractions in MLIR.

Differential Revision: https://reviews.llvm.org/D75987
2020-03-20 14:11:57 -04:00
Shraiysh Vaishay ff77397fcf [mlir] Added llvm.resume and personality functions in LLVM IR Dialect
`llvm.resume` is similar to `llvm.return` except that has to be exactly
one operand and that should be derived from a `llvm.landingpad`
instruction.  Any function having `llvm.landingpad` instruction must
have a personality attribute.

Example:
LLVM IR
```
define dso_local i32 @main() personality i32 (...)* @__gxx_personality_v0 {
  invoke void @foo(i32 42)
          to label %3 unwind label %1

1:                                                ; preds = %0
  %2 = landingpad i8*
          catch i8** @_ZTIi
          catch i8* bitcast (i8** @_ZTIi to i8*)
  resume i8* %2

3:                                                ; preds = %0
  ret i32 1
}
```

MLIR - LLVM IR Dialect

```
llvm.func @main() -> !llvm.i32 attributes {personality = @__gxx_personality_v0} {
    %0 = llvm.mlir.constant(1 : i32) : !llvm.i32
    %1 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**">
    %2 = llvm.bitcast %1 : !llvm<"i8**"> to !llvm<"i8*">
    %3 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**">
    %4 = llvm.mlir.constant(42 : i32) : !llvm.i32
    llvm.invoke @foo(%4) to ^bb2 unwind ^bb1 : (!llvm.i32) -> ()
  ^bb1:	// pred: ^bb0
    %5 = llvm.landingpad (catch %3 : !llvm<"i8**">) (catch %2 : !llvm<"i8*">) : !llvm<"i8*">
    llvm.resume %5 : !llvm<"i8*">
  ^bb2:	// pred: ^bb0
    llvm.return %0 : !llvm.i32
  }
```

Differential Revision: https://reviews.llvm.org/D71888
2020-03-19 13:14:25 +01:00
Nicolas Vasilache 1e43132209 [mlir][LLVM] Add masked reads and writes.
Summary: These intrinsics will be used to lower vector transfer read/write.

Reviewers: aartbik, tetuante, jsetoain

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/D75986
2020-03-18 16:19:07 -04:00
Sagar Jain 76cf14035b [MLIR] Added llvm.fence
This patch adds llvm.fence. I tried not to change the syntax much.

syntax:

LLVM IR
`fence [syncscope("<target-scope>")] <ordering>`

MLIR LLVM Dialect

`llvm.fence [syncscope("<target-scope>")] <ordering>`

example:
LLVM IR: `fence syncscope("agent") seq_cst`
MLIR: `llvm.fence syncscope("agent") seq_cst`

Differential Revision: https://reviews.llvm.org/D75645
2020-03-17 17:53:37 +01:00
Ahmed Taei 18fc42fa33 [mlir][LLVMIR] Add a support for boolean type arguments conversion
Summary:
Otherwise this will fail translating ops with boolean arguments and
added test will fail.

Reviewers: nicolasvasilache, rriddle

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

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D76159
2020-03-13 14:40:26 -07:00
Nicolas Vasilache 63b683a816 [mlir][Vector] Add a vector.matrix_multiply op on 1-D vectors
Summary: This op mirrors the llvm.intr counterpart and allows lowering + type conversions in a progressive fashion.

Differential Revision: https://reviews.llvm.org/D75775
2020-03-09 13:34:03 -04:00
Nicolas Vasilache 55622fd4f3 [mlir][LLVM] Add remaining llvm.matrix intrinsics
Summary:
This revision adds intrinsics for transpose, columnwise.load and columnwise.store
achieving full coverage of the llvm.matrix intrinsics.

Differential Revision: https://reviews.llvm.org/D75852
2020-03-09 13:08:49 -04:00
Nicolas Vasilache cac1ed1f4b [mlir] Introduce an intrinsic for llvm.matrix.multiply
This revision adds the first intrinsic for llvm.matrix.multiply.
This uses the more general `LLVM_OneResultOp` for now since the goal is
to use the
specific Matrix builders that @fhahn has created recently.

When piped through:
```
opt -O3 -enable-matrix | llc -O3 -march=x86-64 -mcpu=skylake-avx512
```
this has been verified to generate ymm instructions.

Additional function attribute support will be needed to generate proper
zmm instructions but at least things run end to end.

Benchmarking will be provided separately with the experimental
metaprogramming
[ModelBuilder](https://github.com/google/iree/tree/master/experimental/ModelBuilder)
tool when ready.
2020-03-05 17:31:41 -05:00
Kiran Chandramohan 92a295eb39 [MLIR, OpenMP] Translation of OpenMP barrier construct to LLVM IR
Summary:
This patch adds support for translation of the OpenMP barrier construct to LLVM
IR. The OpenMP IRBuilder is used for this translation. In this patch the code
for translation is added to the existing LLVM dialect translation to LLVM IR.

The patch includes code changes and a testcase.

Reviewers: jdoerfert, nicolasvasilache, ftynse, rriddle, mehdi_amini

Reviewed By: ftynse, rriddle, mehdi_amini

Differential Revision: https://reviews.llvm.org/D72962
2020-03-05 11:59:36 +00:00
Alex Zinenko efa2d53377 [mlir] error out on unsupported attribute kinds in LLVM global translation
Some attribute kinds are not supported as "value" attributes of
`llvm.mlir.constant` when translating to LLVM IR. We were correctly reporting
an error, but continuing the translation using an "undef" value instead,
leading to a surprising mix of error messages and output IR. Abort the
translation after the error is reported.

Differential Revision: https://reviews.llvm.org/D75450
2020-03-03 17:08:28 +01:00
Sagar Jain d85821dfa6 [MLIR] Added llvm.freeze
This patch adds llvm.freeze & processes undef constants from LLVM IR.

Syntax:
LLVM IR
`<result> = freeze ty <val>`

MLIR LLVM Dialect:
`llvm.freeze val attr-dict : type`

Example:
LLVM IR: `%3 = freeze i32 5`
MLIR: `%6 = llvm.freeze %5 : !llvm.i32`

Differential Revision: https://reviews.llvm.org/D75329
2020-03-02 10:24:01 +01:00
Tim Shen b762bbd4c8 [MLIR] change NVVM.mma.sync to the most useful variant.
Summary:
the .row.col variant turns out to be the popular one, contrary to what I
thought as .row.row. Since .row.col is so prevailing (as I inspect
cuDNN's behavior), I'm going to remove the .row.row support here, which
makes the patch a little bit easier.

Reviewers: ftynse

Subscribers: jholewinski, bixia, sanjoy.google, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D74655
2020-02-18 17:57:04 -08:00
aartbik 83003db430 [mlir] [LLVMIR] add all vector reduction intrinsics to LLVM IR dialect
Summary:
This allows for lowering of VectorOps (and others) into a LLVM IR
that maps directly to efficient implementations on the target machines.

http://llvm.org/docs/LangRef.html#experimental-vector-reduction-intrinsics

Reviewers: ftynse, andydavis1, nicolasvasilache, rriddle

Reviewed By: ftynse, rriddle

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

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D74171
2020-02-10 09:19:05 -08:00
Nicolas Vasilache 499ad45877 [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
2020-02-07 15:38:40 -05:00
River Riddle c33d6970e0 [mlir] Add support for basic location translation to LLVM.
Summary:
This revision adds basic support for emitting line table information when exporting to LLVMIR. We don't yet have a story for supporting all of the LLVM debug metadata, so this revision stubs some features(like subprograms) to enable emitting line tables.

Differential Revision: https://reviews.llvm.org/D73934
2020-02-05 17:41:51 -08:00
Lubomir Litchev fcabccd3d9 [MLIR] Add the sqrt operation to mlir.
Summary: Add and pipe through the sqrt operation for Standard and LLVM dialects.

Reviewers: nicolasvasilache, ftynse

Reviewed By: ftynse

Subscribers: frej, ftynse, merge_guards_bot, flaub, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D73571
2020-01-30 08:07:38 -08:00
Shraiysh Vaishay d242aa245c [MLIR] Added llvm.invoke and llvm.landingpad
Summary:
I have tried to implement `llvm.invoke` and `llvm.landingpad`.

  # `llvm.invoke` is similar to `llvm.call` with two successors added, the first one is the normal label and the second one is unwind label.
  # `llvm.launchpad` takes a variable number of args with either `catch` or `filter` associated with them. Catch clauses are not array types and filter clauses are array types. This is same as the criteria used by LLVM (4f82af81a0/llvm/include/llvm/IR/Instructions.h (L2866))

Examples:
LLVM IR
```
define i32 @caller(i32 %a) personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) {
    invoke i32 @foo(i32 2) to label %success unwind label %fail

  success:
    ret i32 2

  fail:
    landingpad {i8*, i32} catch i8** @_ZTIi catch i8** null catch i8* bitcast (i8** @_ZTIi to i8*) filter [1 x i8] [ i8 1 ]
    ret i32 3
}
```
MLIR LLVM Dialect
```
llvm.func @caller(%arg0: !llvm.i32) -> !llvm.i32 {
  %0 = llvm.mlir.constant(3 : i32) : !llvm.i32
  %1 = llvm.mlir.constant("\01") : !llvm<"[1 x i8]">
  %2 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**">
  %3 = llvm.bitcast %2 : !llvm<"i8**"> to !llvm<"i8*">
  %4 = llvm.mlir.null : !llvm<"i8**">
  %5 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**">
  %6 = llvm.mlir.constant(2 : i32) : !llvm.i32
  %7 = llvm.invoke @foo(%6) to ^bb1 unwind ^bb2 : (!llvm.i32) -> !llvm.i32
^bb1:	// pred: ^bb0
  llvm.return %6 : !llvm.i32
^bb2:	// pred: ^bb0
  %8 = llvm.landingpad (catch %5 : !llvm<"i8**">) (catch %4 : !llvm<"i8**">) (catch %3 : !llvm<"i8*">) (filter %1 : !llvm<"[1 x i8]">) : !llvm<"{ i8*, i32 }">
  llvm.return %0 : !llvm.i32
}
```

Signed-off-by: Shraiysh Vaishay <cs17btech11050@iith.ac.in>

Differential Revision: https://reviews.llvm.org/D72006
2020-01-30 12:55:28 +01:00
Julian Gross 88d6f18225 [mlir] fixed invalid LLVM intrinsics in LLVMOPs.td and llvmir-intrinsics.mlir.
Summary:
The intrinsic operation added multiple type annotations to the llvm intrinsic operations, but only one is needed.
The related tests in llvmir-intrinsics.mlir checked the wrong number and are adjusted as well.

Reviewers: nicolasvasilache, ftynse

Reviewed By: ftynse

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

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D73470
2020-01-28 11:01:22 +01:00
Alex Zinenko 07328944ef [mlir] LLVM import: handle constant data and array/vector aggregates
Summary:
Implement the handling of llvm::ConstantDataSequential and
llvm::ConstantAggregate for (nested) array and vector types when imporitng LLVM
IR to MLIR. In all cases, the result is a DenseElementsAttr that can be used in
either a `llvm.mlir.global` or a `llvm.mlir.constant`. Nested aggregates are
unpacked recursively until an element or a constant data is found. Nested
arrays with innermost scalar type are represented as DenseElementsAttr of
tensor type. Nested arrays with innermost vector type are represented as
DenseElementsAttr with (multidimensional) vector type.

Constant aggregates of struct type are not yet supported as the LLVM dialect
does not have a well-defined way of modeling struct-type constants.

Differential Revision: https://reviews.llvm.org/D72834
2020-01-27 16:15:11 +01:00
Frank Laub fffea2842d [MLIR] LLVM Dialect: add llvm.cmpxchg and improve llvm.atomicrmw custom parser
Summary:
Add a `llvm.cmpxchg` op as a counterpart to LLVM IR's `cmpxchg` instruction.
Note that the `weak`, `volatile`, and `syncscope` attributes are not yet supported.

This will be useful for upcoming parallel versions of affine.for and generally
for reduction-like semantics (especially for reductions that can't make use
of `atomicrmw`, e.g. `fmax`).

Reviewers: ftynse, nicolasvasilache

Reviewed By: ftynse

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

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D72995
2020-01-21 01:09:42 -08:00
Frank Laub 60a0c612df [MLIR] LLVM dialect: Add llvm.atomicrmw
Summary:
This op is the counterpart to LLVM's atomicrmw instruction. Note that
volatile and syncscope attributes are not yet supported.

This will be useful for upcoming parallel versions of `affine.for` and generally
for reduction-like semantics.

Differential Revision: https://reviews.llvm.org/D72741
2020-01-17 21:17:14 +01:00
Alex Zinenko a4a42160c4 [mlir] support translation of multidimensional vectors to LLVM IR
Summary:
MLIR unlike LLVM IR supports multidimensional vector types. Such types are
lowered to nested LLVM IR arrays wrapping an LLVM IR vector for the innermost
dimension of the MLIR vector. MLIR supports constants of such types using
ElementsAttr for values. Introduce support for converting ElementsAttr into
LLVM IR Constant Aggregates recursively. This enables translation of
multidimensional vector constants from MLIR to LLVM IR.

Differential Revision: https://reviews.llvm.org/D72846
2020-01-17 00:05:37 +01:00
Alex Zinenko dc553ce646 [mlir] LLVM import: handle function-typed constants
The current implementation of the LLVM-to-MLIR translation could not handle
functions used as constant values in instructions. The handling is added
trivially as `llvm.mlir.constant` can define constants of function type using
SymbolRef attributes, which works even for functions that have not been
declared yet.
2020-01-15 15:01:49 +01:00
Alex Zinenko d6ea8ff0d7 [mlir] Fix translation of splat constants to LLVM IR
Summary:
When converting splat constants for nested sequential LLVM IR types wrapped in
MLIR, the constant conversion was erroneously assuming it was always possible
to recursively construct a constant of a sequential type given only one value.
Instead, wait until all sequential types are unpacked recursively before
constructing a scalar constant and wrapping it into the surrounding sequential
type.

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

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D72688
2020-01-14 12:37:47 +01:00
Alex Zinenko cda94d3e8a [mlir] Floating constants for import-llvm
Summary:
`mlir-translate -import-llvm test.ll`  was going into segmentation fault if `test.ll` had `float` or `double` constants.
For example,
```
%3 = fadd double 3.030000e+01, %0
```
Now, it is handled in `Importer::getConstantAsAttr` (similar behaviour as normal integers)
Added tests for FP arithmetic

Reviewers: ftynse, mehdi_amini

Reviewed By: ftynse, mehdi_amini

Subscribers: shauheen, mehdi_amini, rriddle, jpienaar, burmako, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D71912
2019-12-27 11:48:24 +01:00
Manuel Freiberger 22954a0e40 Add integer bit-shift operations to the standard dialect.
Rename the 'shlis' operation in the standard dialect to 'shift_left'. Add tests
for this operation (these have been missing so far) and add a lowering to the
'shl' operation in the LLVM dialect.

Add also 'shift_right_signed' (lowered to LLVM's 'ashr') and 'shift_right_unsigned'
(lowered to 'lshr').

The original plan was to name these operations 'shift.left', 'shift.right.signed'
and 'shift.right.unsigned'. This works if the operations are prefixed with 'std.'
in MLIR assembly. Unfortunately during import the short form is ambigous with
operations from a hypothetical 'shift' dialect. The best solution seems to omit
dots in standard operations for now.

Closes tensorflow/mlir#226

PiperOrigin-RevId: 286803388
2019-12-22 10:02:13 -08:00
Marcel Koester 6054610bbe Added LLVM ops and lowering phases from standard dialect for FAbs, FCeil, Cos, FNeg, CopySign.
Added test cases for the newly added LLVM operations and lowering features.

Closes tensorflow/mlir#300

COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/300 from dfki-jugr:std_to_llvm da6168bbc1a369ae2e99ad3881fdddd82f075dd4
PiperOrigin-RevId: 286231169
2019-12-18 11:42:43 -08:00
Uday Bondhugula 47034c4bc5 Introduce prefetch op: affine -> std -> llvm intrinsic
Introduce affine.prefetch: op to prefetch using a multi-dimensional
subscript on a memref; similar to affine.load but has no effect on
semantics, but only on performance.

Provide lowering through std.prefetch, llvm.prefetch and map to llvm's
prefetch instrinsic. All attributes reflected through the lowering -
locality hint, rw, and instr/data cache.

  affine.prefetch %0[%i, %j + 5], false, 3, true : memref<400x400xi32>

Signed-off-by: Uday Bondhugula <uday@polymagelabs.com>

Closes tensorflow/mlir#225

COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/225 from bondhugula:prefetch 4c3b4e93bc64d9a5719504e6d6e1657818a2ead0
PiperOrigin-RevId: 286212997
2019-12-18 10:00:04 -08:00
Christian Sigg 9b85582682 Automated rollback of commit f68ac464d8
PiperOrigin-RevId: 285162061
2019-12-12 03:48:38 -08:00
Christian Sigg f68ac464d8 Switch from shfl.bfly to shfl.down.
Both work for the current use case, but the latter allows implementing
prefix sums and is a little easier to understand for partial warps.

PiperOrigin-RevId: 285145287
2019-12-12 01:28:01 -08:00
Nicolas Vasilache 9dfa84a269 Add std.log* and llvm.intr.log* that correspond to the LLVMIR intrinsics
PiperOrigin-RevId: 285073483
2019-12-11 15:25:34 -08:00
Alex Zinenko d5e627f84b Introduce Linkage attribute to the LLVM dialect
LLVM IR supports linkage on global objects such as global variables and
functions. Introduce the Linkage attribute into the LLVM dialect, backed by an
integer storage. Use this attribute on LLVM::GlobalOp and make it mandatory.
Implement parsing/printing of the attribute and conversion to LLVM IR.

See tensorflow/mlir#277.

PiperOrigin-RevId: 283309328
2019-12-02 03:28:10 -08:00
MLIR Team 1012c492f0 Allow LLVM::ExtractElementOp to have non-i32 indices.
Also change the text format a bit, so that indices are braced by squares.

PiperOrigin-RevId: 282437095
2019-11-25 14:44:52 -08:00
Alex Zinenko 09e8e7107a mlir-translate: support -verify-diagnostics
MLIR translation tools can emit diagnostics and we want to be able to check if
it is indeed the case in tests. Reuse the source manager error handlers
provided for mlir-opt to support the verification in mlir-translate. This
requires us to change the signature of the functions that are registered to
translate sources to MLIR: it now takes a source manager instead of a memory
buffer.

PiperOrigin-RevId: 279132972
2019-11-07 11:42:46 -08:00
Eric Schweitz 0d545921ea Add support for the LLVM FNeg instruction
Closes tensorflow/mlir#216

COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/216 from schweitzpgi:llvmir-fneg-op f9b5f185845d671b745ab6fc213d5d9aff044b34
PiperOrigin-RevId: 278795325
2019-11-06 00:02:10 -08:00
James Molloy 250a11ae0f [llvm] Allow GlobalOp to take a region for complex initializers
This allows GlobalOp to either take a value attribute (for simple constants) or a region that can
contain IR instructions (that must be constant-foldable) to create a ConstantExpr initializer.

Example:
  // A complex initializer is constructed with an initializer region.
  llvm.mlir.global constant @int_gep() : !llvm<"i32*"> {
    %0 = llvm.mlir.addressof @g2 : !llvm<"i32*">
    %1 = llvm.mlir.constant(2 : i32) : !llvm.i32
    %2 = llvm.getelementptr %0[%1] : (!llvm<"i32*">, !llvm.i32) -> !llvm<"i32*">
    llvm.return %2 : !llvm<"i32*">
  }
PiperOrigin-RevId: 278717836
2019-11-05 15:11:01 -08:00
James Molloy 6b534ecbcb [llvm] Add initial import of LLVM modules to mlir-translate
This adds an importer from LLVM IR or bitcode to the LLVM dialect. The importer is registered with mlir-translate.

Known issues exposed by this patch but not yet fixed:
  * Globals' initializers are attributes, which makes it impossible to represent a ConstantExpr. This will be fixed in a followup.
  * icmp returns i32 rather than i1.
  * select and a couple of other instructions aren't implemented.
  * llvm.cond_br takes its successors in a weird order.

The testing here is known to be non-exhaustive.

I'd appreciate feedback on where this functionality should live. It looks like the translator *from MLIR to LLVM* lives in Target/, but the SPIR-V deserializer lives in Dialect/ which is why I've put this here too.

PiperOrigin-RevId: 278711683
2019-11-05 14:41:38 -08:00
MLIR Team 1f43d0d000 [NVVM] Add mma.sync operation.
PiperOrigin-RevId: 278440547
2019-11-04 12:36:37 -08:00
James Molloy 96531e2f87 [mlir][llvm] Add missing cast ops
Also adds a builder method for fcmp, identical to that for icmp.

PiperOrigin-RevId: 277923158
2019-11-01 07:32:09 -07:00
Christian Sigg c3e56cd12c Get active source lane predicate from shuffle instruction.
nvvm.shfl.sync.bfly optionally returns a predicate whether source lane was active. Support for this was added to clang in https://reviews.llvm.org/D68892.

Add an optional 'pred' unit attribute to the instruction to return this predicate. Specify this attribute in the partial warp reduction so we don't need to manually compute the predicate.

PiperOrigin-RevId: 275616564
2019-10-19 01:53:25 -07:00
Alex Zinenko 71b82bcbf6 LLVM Dialect: introduce llvm.mlir.null operation
Similarly to `llvm.mlir.undef`, this auxiliary operation creates an SSA value
that corresponds to `null` in LLVM IR.  This operation is necessary to model
sizeof(<...>) behavior when allocating memory.

PiperOrigin-RevId: 274158760
2019-10-11 06:32:24 -07:00
Alex Zinenko 5e7959a353 Use llvm.func to define functions with wrapped LLVM IR function type
This function-like operation allows one to define functions that have wrapped
LLVM IR function type, in particular variadic functions. The operation was
added in parallel to the existing lowering flow, this commit only switches the
flow to use it.

Using a custom function type makes the LLVM IR dialect type system more
consistent and avoids complex conversion rules for functions that previously
had to use the built-in function type instead of a wrapped LLVM IR dialect type
and perform conversions during the analysis.

PiperOrigin-RevId: 273910855
2019-10-10 01:34:06 -07:00
Alexander Belyaev c9c24ca23b Add exp operation to LLVMOPs.td.
PiperOrigin-RevId: 273718958
2019-10-09 04:19:43 -07:00
Deven Desai 956a831130 [ROCm] Fix the return type for the device function calls from i32 to i64.
This is matching what the runtime library is expecting.

Closes tensorflow/mlir#171

COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/171 from deven-amd:deven-rocdl-device-func-i64 80762629a8c34e844ebdc542b34dd783990db9db
PiperOrigin-RevId: 273640767
2019-10-08 17:41:42 -07:00
Christian Sigg f479f816f9 Add integer shift ops to LLVM dialect.
PiperOrigin-RevId: 272140049
2019-09-30 22:56:28 -07:00
Deven Desai fee40fef5c [ROCm] Adding ROCDL Dialect.
This commit introduces the ROCDL Dialect (i.e. the ROCDL ops + the code to lower those ROCDL ops to LLWM intrinsics/functions). Think of ROCDL Dialect as analogous to the NVVM Dialect, but for AMD GPUs. This patch contains just the essentials needed to get a simple example up and running. We expect to make further additions to the ROCDL Dialect.

This is the first of 3 commits, the follow-up will be:
 * add a pass that lowers GPU Dialect to ROCDL Dialect
 * add a "mlir-rocm-runner" utility

Closes tensorflow/mlir#146

COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/146 from deven-amd:deven-rocdl-dialect e78e8005c75a78912631116c78dc844fcc4b0de9
PiperOrigin-RevId: 271511259
2019-09-27 00:22:32 -07:00
Manuel Freiberger 2c11997d48 Add integer sign- and zero-extension and truncation to standard.
This adds sign- and zero-extension and truncation of integer types to the
standard dialects. This allows to perform integer type conversions without
having to go to the LLVM dialect and introduce custom type casts (between
standard and LLVM integer types).

Closes tensorflow/mlir#134

COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/134 from ombre5733:sext-zext-trunc-in-std c7657bc84c0ca66b304e53ec03797e09152e4d31
PiperOrigin-RevId: 270479722
2019-09-21 16:14:56 -07:00
Christian Sigg 33a3a91ba2 Make GlobalOp's value attribute optional.
Make GlobalOp's value attribute an OptionalAttr. Change code that uses the value to handle 'nullopt'. Translate an unitialized value attribute to llvm::UndefValue.

PiperOrigin-RevId: 270423646
2019-09-21 01:20:28 -07:00
MLIR Team e79bfefb89 Add address space attribute to LLVMIR's GlobalOp.
PiperOrigin-RevId: 270012505
2019-09-19 04:50:46 -07:00
MLIR Team 5e65dafbfa Add warpsize and laneid intrinsics to NVVM dialect.
PiperOrigin-RevId: 268041263
2019-09-09 11:38:03 -07:00
MLIR Team 2f13df13b0 Add support for array-typed constants.
PiperOrigin-RevId: 267121729
2019-09-04 03:46:06 -07:00
Alex Zinenko c335d9d313 LLVM dialect: prefix auxiliary operations with "mlir."
Some of the operations in the LLVM dialect are required to model the LLVM IR in
MLIR, for example "constant" operations are needed to declare a constant value
since MLIR, unlike LLVM, does not support immediate values as operands.  To
avoid confusion with actual LLVM operations, we prefix such axuiliary
operations with "mlir.".

PiperOrigin-RevId: 266942838
2019-09-03 09:10:56 -07:00
MLIR Team 696fcb7520 Add 3 additional intrinsic ops to NVVM dialect, in preparation to implement block-wide reduce.
PiperOrigin-RevId: 265720077
2019-08-27 10:56:18 -07:00
Eric Schweitz 761d57d187 Add FPToSI/FPExt/FPTrunc cast ops to the LLVM dialect.
Closes tensorflow/mlir#99

PiperOrigin-RevId: 265538731
2019-08-26 14:19:19 -07:00
River Riddle d906f84b52 Add iterator support to ElementsAttr and SparseElementsAttr.
This will allow iterating the values of a non-opaque ElementsAttr, with all of the types currently supported by DenseElementsAttr. This should help reduce the amount of specialization on DenseElementsAttr.

PiperOrigin-RevId: 264968151
2019-08-22 18:59:24 -07:00
River Riddle b618221350 Automated rollback of commit b9dc2e4818
PiperOrigin-RevId: 264672975
2019-08-21 13:01:03 -07:00
River Riddle b9dc2e4818 Add iterator support to ElementsAttr and SparseElementsAttr.
This will allow iterating the values of a non-opaque ElementsAttr, with all of the types currently supported by DenseElementsAttr. This should help reduce the amount of specialization on DenseElementsAttr.

PiperOrigin-RevId: 264637293
2019-08-21 10:23:44 -07:00
Alex Zinenko 0f974817b5 LLVM dialect: prefix operations that correspond to intrinsics with "intr."
LLVM intrinsics have an open name space and their names can potentially overlap
with names of LLVM instructions (LLVM intrinsics are functions, not
instructions).  In MLIR, LLVM intrinsics are modeled as operations, so it needs
to make sure their names cannot clash with the instructions.  Use the "intr."
prefix for intrinsics in the LLVM dialect.

PiperOrigin-RevId: 264372173
2019-08-20 06:38:52 -07:00
Nicolas Vasilache c9f37fca37 Add alignment support for llvm.alloca
Extend the LLVM dialect AllocaOp with an alignment attribute.

PiperOrigin-RevId: 264068306
2019-08-18 18:55:14 -07:00
Alex Zinenko 5f0a843144 LLVM dialect: introduce fmuladd intrinsic as operation
This operation is important to achieve decent performance in computational
kernels.  In LLVM, it is implemented as an intrinsic (through function
declaration and function call).  Thanks to MLIR's extendable set of operations,
it does not have to differentiate between built-ins and intrinsics, so fmuladd
is introduced as a general type-polymorphic operation.  Custom printing and
parsing will be added later.

PiperOrigin-RevId: 263106305
2019-08-13 03:40:51 -07:00
Alex Zinenko 2dd38b09c1 LLVM dialect: introduce llvm.addressof to access globals
This instruction is a local counterpart of llvm.global that takes a symbol
reference to a global and produces an SSA value containing the pointer to it.
Used in combination, these two operations allow one to use globals with other
operations expecting SSA values.  At a cost of IR indirection, we make sure the
functions don't implicitly capture the surrounding SSA values and remain
suitable for parallel processing.

PiperOrigin-RevId: 262908622
2019-08-12 06:10:54 -07:00
Alex Zinenko 68451df267 LLVM dialect and translation: support global strings
Unlike regular constant values, strings must be placed in some memory and
referred to through a pointer to that memory.  Until now, they were not
supported in function-local constant declarations with `llvm.constant`.
Introduce support for global strings using `llvm.global`, which would translate
them into global arrays in LLVM IR and thus make sure they have some memory
allocated for storage.

PiperOrigin-RevId: 262569316
2019-08-09 09:00:13 -07:00
Alex Zinenko b9ff2dd87e Translation to LLVM: support llvm.global
Add support for translating recently introduced llvm.global operations to
global variables in the LLVM IR proper.

PiperOrigin-RevId: 262564700
2019-08-09 08:30:42 -07:00
Nicolas Vasilache 92dc127ab3 Add support for vector ops in the LLVM dialect
This CL is step 1/n towards building a simple, programmable and portable vector abstraction in MLIR that can go all the way down to generating assembly vector code via LLVM's opt and llc tools.

This CL adds the 3 instructions `llvm.extractelement`, `llvm.insertelement` and `llvm.shufflevector` as documented in the LLVM LangRef "Vector Instructions" section.

The "Experimental Vector Reduction Intrinsics" are left out for now and can be added in the future on a per-need basis.

Appropriate roundtrip and LLVM Target tests are added.

PiperOrigin-RevId: 262542095
2019-08-09 05:25:31 -07:00
Nagy Mostafa 48fdc8d7a3 Add support for floating-point comparison 'fcmp' to the LLVM dialect.
This adds support for fcmp to the LLVM dialect and adds any necessary lowerings, as well as support for EDSCs.

Closes tensorflow/mlir#69

PiperOrigin-RevId: 262475255
2019-08-08 18:29:48 -07:00
Eric Schweitz 881b238d7e Add the LLVM IR unreachable instruction to the LLVMIR dialect.
http://llvm.org/docs/LangRef.html#unreachable-instruction

Closes tensorflow/mlir#64

PiperOrigin-RevId: 262301557
2019-08-08 01:06:00 -07:00
Denis Khalikov b36e3be3fc [mlir-translate] Fix test suite.
llvm ir printer was changed at LLVM r367755.
Prints value numbers for unnamed functions argument.

Closes tensorflow/mlir#67

COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/67 from denis0x0D:sandbox/fix_mlir_translate ae46844e66f34a02e0cf86782ddadc5bce58b30d
PiperOrigin-RevId: 261640048
2019-08-05 01:39:55 -07:00
River Riddle 679a3b4191 Change the attribute dictionary syntax to separate name and value with '='.
The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations:

Old:
  "foo: 10 : i32"

New:
  "foo = 10 : i32"
PiperOrigin-RevId: 255097928
2019-06-25 19:06:34 -07:00
River Riddle 4842b2d42e Modify the syntax of the the ElementsAttrs to print the type as a colon type.
This is the standard syntax for types on operations, and is also already used by IntegerAttr and FloatAttr.

Example:
  dense<5> : tensor<i32>
  dense<[3]> : tensor<1xi32>
PiperOrigin-RevId: 255069157
2019-06-25 16:06:58 -07:00
Alex Zinenko f35d0c8570 NVVM target: emit nvvm.annotations for kernel functions
PTX backend in LLVM expects additional module-level metadata
`!nvvm.annotations` that lists functions that can be used as GPU kernels.
Generate this metadata based on the `gpu.kernel` attribute attached to
functions.  This attribute is added automatically by the kernel outlining pass
in the GPU dialect lowering flow.

PiperOrigin-RevId: 254957345
2019-06-25 09:19:27 -07:00
River Riddle 6a0555a875 Refactor SplatElementsAttr to inherit from DenseElementsAttr as opposed to being a separate Attribute type. DenseElementsAttr provides a better internal representation for splat values as well as better API for accessing elements.
PiperOrigin-RevId: 253138287
2019-06-19 23:01:52 -07:00
Stephan Herhut cb348dff8a Add support for llvm.constant with StringAttr as value.
These are translated to an llvm::ConstantDataArray on translation to llvm IR
    proper.

--

PiperOrigin-RevId: 249813111
2019-06-01 19:59:54 -07:00
Stephan Herhut b52112275d Add LLVM::IntToPtrOp and LLVM::PtrToIntOp to LLVM dialect.
--

PiperOrigin-RevId: 249604199
2019-06-01 19:57:34 -07:00
River Riddle c33862b0ed Refactor FunctionAttr to hold the internal function reference by name instead of pointer. The one downside to this is that the function reference held by a FunctionAttr needs to be explicitly looked up from the parent module. This provides several benefits though:
* There is no longer a need to explicitly remap function attrs.
      - This removes a potentially expensive call from the destructor of Function.
      - This will enable some interprocedural transformations to now run intraprocedurally.
      - This wasn't scalable and forces dialect defined attributes to override
        a virtual function.
    * Replacing a function is now a trivial operation.
    * This is a necessary first step to representing functions as operations.

--

PiperOrigin-RevId: 249510802
2019-06-01 19:56:54 -07:00
Stephan Herhut 5d7231d812 Add transformation of the NVVM dialect to an LLVM module. Only handles
the generation of intrinsics out of NVVM index ops for now.

--

PiperOrigin-RevId: 245933152
2019-05-06 08:22:14 -07:00
Stephan Herhut d6037276af Add conversion of StandardOps and, or and xor to LLVM dialect.
--

PiperOrigin-RevId: 242831203
2019-04-11 10:52:02 -07:00
Mehdi Amini 7286d43920 Introduce std.varargs attribute to mark variadic arguments functions
This is only teaching the LLVM converter to propagate the attribute onto
    the function type. MLIR will not recognize this arguments, so it would only
    be useful when calling for example `printf` with the same arguments across
    a module. Since varargs is part of the ABI lowering, this is not NFC.

--

PiperOrigin-RevId: 242382427
2019-04-07 18:22:56 -07:00
Chris Lattner 72441fcbf2 Change the asmprinter to use pretty syntax for dialect types when it can,
making the IR dumps much nicer.

    This is part 2/3 of the path to making dialect types more nice.  Part 3/3 will
    slightly generalize the set of characters allowed in pretty types and make it
    more principled.

--

PiperOrigin-RevId: 242249955
2019-04-07 18:21:13 -07:00
Alex Zinenko 736bef7386 Introduce custom format for the LLVM IR Dialect
Historically, the LLVM IR dialect has been using the generic form of MLIR
    operation syntax.  It is verbose and often redundant.  Introduce the custom
    printing and parsing for all existing operations in the LLVM IR dialect.
    Update the relevant documentation and tests.

--

PiperOrigin-RevId: 241617393
2019-04-02 16:31:58 -07:00
River Riddle fdef161592 Remove "<label>" from the llvm basic block CHECK names.
PiperOrigin-RevId: 239898185
2019-03-29 17:32:06 -07:00
Dimitrios Vytiniotis 480cc2b063 Using llvm.noalias attribute when generating LLVMIR.
PiperOrigin-RevId: 237063104
2019-03-29 17:01:11 -07:00
Alex Zinenko 8cc50208a6 LLVM IR Dialect: unify call and call0 operations
When the LLVM IR dialect was implemented, TableGen operation definition scheme
did not support operations with variadic results.  Therefore, the `call`
instruction was split into `call` and `call0` for the single- and zero-result
calls (LLVM does not support multi-result operations).  Unify `call` and
`call0` using the recently added TableGen support for operations with Variadic
results.  Explicitly verify that the new operation has 0 or 1 results.  As a
side effect, this change enables clean-ups in the conversion to the LLVM IR
dialect that no longer needs to rely on wrapped LLVM IR void types when
constructing zero-result calls.

PiperOrigin-RevId: 236119197
2019-03-29 16:49:59 -07:00
Alex Zinenko 1da1b4c321 LLVM IR dialect and translation: support conditional branches with arguments
Since the goal of the LLVM IR dialect is to reflect LLVM IR in MLIR, the
dialect and the conversion procedure must account for the differences betweeen
block arguments and LLVM IR PHI nodes. In particular, LLVM IR disallows PHI
nodes with different values coming from the same source. Therefore, the LLVM IR
dialect now disallows `cond_br` operations that have identical successors
accepting arguments, which would lead to invalid PHI nodes. The conversion
process resolves the potential PHI source ambiguity by injecting dummy blocks
if the same block is used more than once as a successor in an instruction.
These dummy blocks branch unconditionally to the original successors, pass them
the original operands (available in the dummy block because it is dominated by
the original block) and are used instead of them in the original terminator
operation.

PiperOrigin-RevId: 235682798
2019-03-29 16:43:05 -07:00
Alex Zinenko c98a87cc06 Lower standard DivF and RemF operations to the LLVM IR dialect
Add support for lowering DivF and RemF to LLVM::FDiv and LLMV::FRem
respectively.  The lowering is a trivial one-to-one transformation.
The corresponding operations already existed in the LLVM IR dialect and can be
lowered to the LLVM IR proper.  Add the necessary tests for scalar and vector
forms.

PiperOrigin-RevId: 234984608
2019-03-29 16:36:56 -07:00
Alex Zinenko ffc9043604 LLVM dialect conversion and target: support indirect calls
Add support for converting MLIR `call_indirect` instructions to the LLVM IR
dialect.  In LLVM IR, the same instruction is used for direct and indirect
calls.  In the dialect, we have `llvm.call` and `llvm.call0` to work around the
absence of the void type in MLIR.  For direct calls, the callee is stored as
instruction attribute.  Use the same pair of instructions for indirect calls by
omitting the callee attribute.  In the MLIR to LLVM IR translator, check the
presence of attribute to decide whether to construct a direct or an indirect
call using different LLVM IR Builder functions.

Add support for converting constants of function type to the LLVM IR dialect
and for translating them to the LLVM IR proper.  The `llvm.constant` operation
works similarly to other types: its attribute has MLIR function type but the
value it produces has LLVM IR function type wrapped in the dialect type.  While
lowering, look up the pointer to the converted function in the corresponding
mapping.

PiperOrigin-RevId: 234132351
2019-03-29 16:28:56 -07:00
Alex Zinenko 50700b8122 Reimplement LLVM IR translation to use the MLIR LLVM IR dialect
Original implementation of the translation from MLIR to LLVM IR operated on the
Standard+BuiltIn dialect, with a later addition of the SuperVector dialect.
This required the translation to be aware of a potetially large number of other
dialects as the infrastructure extended.  With the recent introduction of the
LLVM IR dialect into MLIR, the translation can be switched to only translate
the LLVM IR dialect, and the translation of the operations becomes largely
mechanical.

The reimplementation of the translator follows the lines of the original
translator in function and basic block conversion.  In particular, block
arguments are converted to LLVM IR PHI nodes, which are connected to their
sources after all blocks of a function had been converted.  Thanks to LLVM IR
types being wrapped in the MLIR LLVM dialect type, type conversion is
simplified to only convert function types, all other types are simply
unwrapped.  Individual instructions are constructed using the LLVM IRBuilder,
which has a great potential for being table-generated from the LLVM IR dialect
operation definitions.

The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR
dialect.  While it is now redundant with the dialect conversion test, the point
of the exercise is to guarantee exactly the same LLVM IR is emitted.  (Only the
name of the allocation function is changed from `__mlir_alloc` to `alloc` in
the CHECK lines.)  It will be simplified in a follow-up commit.

PiperOrigin-RevId: 233842306
2019-03-29 16:27:10 -07:00
Alex Zinenko caa7e70627 LLVM IR lowering: support integer division and remainder operations
These operations trivially map to LLVM IR counterparts for operands of scalar
and (one-dimensional) vector type.  Multi-dimensional vector and tensor type
operands would fail type conversion before the operation conversion takes
place.  Add tests for scalar and vector cases.  Also add a test for vector
`select` instruction for consistency with other tests.

PiperOrigin-RevId: 228077564
2019-03-29 14:59:07 -07:00
Chris Lattner bbf362b784 Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead.
The entire compiler now looks at structural properties of the function (e.g.
does it have one block, does it contain an if/for stmt, etc) so the only thing
holding up this difference is round tripping through the parser/printer syntax.
Removing this shrinks the compile by ~140LOC.

This is step 31/n towards merging instructions and statements.  The last step
is updating the docs, which I will do as a separate patch in order to split it
from this mostly mechanical patch.

PiperOrigin-RevId: 227540453
2019-03-29 14:51:37 -07:00
Alex Zinenko 0565067495 LLVM IR Lowering: support "select"
This commit adds support for the "select" operation that lowers directly into
its LLVM IR counterpart.  A simple test is included.

PiperOrigin-RevId: 227527893
2019-03-29 14:51:08 -07:00
Chris Lattner 8ef2552df7 Have the asmprinter take advantage of the new capabilities of the asmparser, by
printing the entry block in a CFG function's argument line.  Since I'm touching
all of the testcases anyway, change the argument list from printing as
"%arg : type" to "%arg: type" which is more consistent with bb arguments.

In addition to being more consistent, this is a much nicer look for cfg functions.

PiperOrigin-RevId: 227240069
2019-03-29 14:46:29 -07:00
Chris Lattner 37579ae8c4 Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR
syntax.

PiperOrigin-RevId: 227234174
2019-03-29 14:45:59 -07:00
Chris Lattner 5b9c3f7cdb Tidy up references to "basic blocks" that should refer to blocks now. NFC.
PiperOrigin-RevId: 227196077
2019-03-29 14:44:59 -07:00
Alex Zinenko 9403f80dd3 LLVM IR lowering: support SubIOp and SubFOp
The binary subtraction operations were not supported by the lowering because
they were not essential for the testing flow.  Add support for these
operations.

PiperOrigin-RevId: 226941463
2019-03-29 14:37:05 -07:00
Alex Zinenko 359835eb27 LLVM IR lowering: support 1D vector operations
Introduce initial support for 1D vector operations.  LLVM does not support
higher-dimensional vectors so the caller must make sure they don't appear in
the input MLIR.  Handle the presence of higher-dimensional vectors by failing
gracefully.

Introduce the type conversion for 1D vector types and hook it up with the rest
of the type convresion system.  Support "splat" constants for vector types.  As
a side effect, this refactors constant operation emission by separating out
scalar integer constants into a separate case and by extracting out the helper
function for scalar float construction.  Existing binary operations apply to
vectors transparently.

PiperOrigin-RevId: 225172349
2019-03-29 14:26:37 -07:00
Alex Zinenko dee51d0961 LLVM IR Lowering: support multi-value returns.
Unlike MLIR, LLVM IR does not support functions that return multiple values.
Simulate this by packing values into the LLVM structure type in the same order
as they appear in the MLIR return.  If the function returns only a single
value, return it directly without packing.

PiperOrigin-RevId: 223964886
2019-03-29 14:15:56 -07:00
Alex Zinenko e7f43c8361 LLVM IR lowering: support 'dim' operation.
Add support for translating 'dim' opreation on MemRefs to LLVM IR.  For a
static size, this operation merely defines an LLVM IR constant value that may
not appear in the output IR if not used (and had not been removed before by
DCE).  For a dynamic size, this operation is translated into an access to the
MemRef descriptor that contains the dynamic size.

PiperOrigin-RevId: 223160774
2019-03-29 14:11:10 -07:00
Alex Zinenko 90d1b6b5f2 LLVM IR lowering: support simple MemRef types
Introduce initial support for MemRef types, including type conversion,
allocation and deallocation, read and write element-wise access, passing
MemRefs to and returning from functions.  Affine map compositions and
non-default memory spaces are NOT YET supported.

Lowered code needs to handle potentially dynamic sizes of the MemRef.  To do
so, it replaces a MemRef-typed value with a special MemRef descriptor that
carries the data and the dynamic sizes together.  A MemRef type is converted to
LLVM's first-class structure type with the first element being the pointer to
the data buffer with data layed out linearly, followed by as many integer-typed
elements as MemRef has dynamic sizes.  The type of these elements is that of
MLIR index lowered to LLVM.  For example, `memref<?x42x?xf32>` is converted to
`{ f32*, i64, i64 }` provided `index` is lowered to `i64`.  While it is
possible to convert MemRefs with fully static sizes to simple pointers to their
elemental types, we opted for consistency and convert them to the
single-element structure.  This makes the conversion code simpler and the
calling convention of the generated LLVM IR functions consistent.

Loads from and stores to a MemRef element are lowered to a sequence of LLVM
instructions that, first, computes the linearized index of the element in the
data buffer using the access indices and combining the static sizes with the
dynamic sizes stored in the descriptor, and then loads from or stores to the
buffer element indexed by the linearized subscript.  While some of the index
computations may be redundant (i.e., consecutive load and store to the same
location in the same scope could reuse the linearized index), we emit them for
every operation.  A subsequent optimization pass may eliminate them if
necessary.

MemRef allocation and deallocation is performed using external functions
`__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by
the caller.  These functions behave similarly to `malloc` and `free`, but can
be extended to support different memory spaces in future.  Allocation and
deallocation instructions take care of casting the pointers.  Prior to calling
the allocation function, the emitted code creates an SSA Value for the
descriptor and uses it to store the dynamic sizes of the MemRef passed to the
allocation operation.  It further emits instructions that compute the dynamic
amount of memory to allocate in bytes.  Finally, the allocation stores the
result of calling the `__mlir_alloc` in the MemRef descriptor.  Deallocation
extracts the pointer to the allocated memory from the descriptor and calls
`__mlir_free` on it.  The descriptor itself is not modified and, being
stack-allocated, ceases to exist when it goes out of scope.

MLIR functions that access MemRef values as arguments or return them are
converted to LLVM IR functions that accept MemRef descriptors as LLVM IR
structure types by value.  This significantly simplifies the calling convention
at the LLVM IR level and avoids handling descriptors in the dynamic memory,
however is not always comaptible with LLVM IR functions emitted from C code
with similar signatures.  A separate LLVM pass may be introduced in the future
to provide C-compatible calling conventions for LLVM IR functions generated
from MLIR.

PiperOrigin-RevId: 223134883
2019-03-29 14:10:55 -07:00
Alex Zinenko ac6bfa6780 Lower scalar parts of CFG functions to LLVM IR
Initial restricted implementaiton of the MLIR to LLVM IR translation.
Introduce a new flow into the mlir-translate tool taking an MLIR module
containing CFG functions only and producing and LLVM IR module.  The MLIR
features supported by the translator are as follows:
- primitive and function types;
- integer constants;
- cfg and ext functions with 0 or 1 return values;
- calls to these functions;
- basic block conversion translation of arguments to phi nodes;
- conversion between arguments of the first basic block and function arguments;
- (conditional) branches;
- integer addition and comparison operations.

Are NOT supported:
- vector and tensor types and operations on them;
- memrefs and operations on them;
- allocations;
- functions returning multiple values;
- LLVM Module triple and data layout (index type is hardcoded to i64).

Create a new MLIR library and place it under lib/Target/LLVMIR.  The "Target"
library group is similar to the one present in LLVM and is intended to contain
all future public MLIR translation targets.

The general flow of MLIR to LLVM IR convresion will include several lowering
and simplification passes on the MLIR itself in order to make the translation
as simple as possible.  In particular, ML functions should be transformed to
CFG functions by the recently introduced pass, operations on structured types
will be converted to sequences of operations on primitive types, complex
operations such as affine_apply will be converted into sequence of primitive
operations, primitive operations themselves may eventually be converted to an
LLVM dialect that uses LLVM-like operations.

Introduce the first translation test so that further changes make sure the
basic translation functionality is not broken.

PiperOrigin-RevId: 222400112
2019-03-29 14:07:01 -07:00