maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/mlir/test/Dialect/LLVMIR/roundtrip.mlir

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

306 lines
14 KiB
MLIR
Raw Normal View History

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 20:24:47 +08:00
// RUN: mlir-opt %s | mlir-opt | FileCheck %s
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
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-06 14:56:49 +08:00
// CHECK-LABEL: func @ops(%arg0: !llvm.i32, %arg1: !llvm.float)
func @ops(%arg0 : !llvm.i32, %arg1 : !llvm.float) {
Fix minor spelling tweaks (NFC) Closes tensorflow/mlir#175 PiperOrigin-RevId: 275726876
2019-10-21 00:44:06 +08:00
// Integer arithmetic binary operations.
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
//
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-06 14:56:49 +08:00
// CHECK-NEXT: %0 = llvm.add %arg0, %arg0 : !llvm.i32
// CHECK-NEXT: %1 = llvm.sub %arg0, %arg0 : !llvm.i32
// CHECK-NEXT: %2 = llvm.mul %arg0, %arg0 : !llvm.i32
// CHECK-NEXT: %3 = llvm.udiv %arg0, %arg0 : !llvm.i32
// CHECK-NEXT: %4 = llvm.sdiv %arg0, %arg0 : !llvm.i32
// CHECK-NEXT: %5 = llvm.urem %arg0, %arg0 : !llvm.i32
// CHECK-NEXT: %6 = llvm.srem %arg0, %arg0 : !llvm.i32
// CHECK-NEXT: %7 = llvm.icmp "ne" %arg0, %arg0 : !llvm.i32
%0 = llvm.add %arg0, %arg0 : !llvm.i32
%1 = llvm.sub %arg0, %arg0 : !llvm.i32
%2 = llvm.mul %arg0, %arg0 : !llvm.i32
%3 = llvm.udiv %arg0, %arg0 : !llvm.i32
%4 = llvm.sdiv %arg0, %arg0 : !llvm.i32
%5 = llvm.urem %arg0, %arg0 : !llvm.i32
%6 = llvm.srem %arg0, %arg0 : !llvm.i32
%7 = llvm.icmp "ne" %arg0, %arg0 : !llvm.i32
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
Replace remaining usages of the Instruction class with Operation. PiperOrigin-RevId: 240777521
2019-03-28 23:24:38 +08:00
// Floating point binary operations.
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
//
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-06 14:56:49 +08:00
// CHECK-NEXT: %8 = llvm.fadd %arg1, %arg1 : !llvm.float
// CHECK-NEXT: %9 = llvm.fsub %arg1, %arg1 : !llvm.float
// CHECK-NEXT: %10 = llvm.fmul %arg1, %arg1 : !llvm.float
// CHECK-NEXT: %11 = llvm.fdiv %arg1, %arg1 : !llvm.float
// CHECK-NEXT: %12 = llvm.frem %arg1, %arg1 : !llvm.float
%8 = llvm.fadd %arg1, %arg1 : !llvm.float
%9 = llvm.fsub %arg1, %arg1 : !llvm.float
%10 = llvm.fmul %arg1, %arg1 : !llvm.float
%11 = llvm.fdiv %arg1, %arg1 : !llvm.float
%12 = llvm.frem %arg1, %arg1 : !llvm.float
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
Replace remaining usages of the Instruction class with Operation. PiperOrigin-RevId: 240777521
2019-03-28 23:24:38 +08:00
// Memory-related operations.
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
//
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-06 14:56:49 +08:00
// CHECK-NEXT: %13 = llvm.alloca %arg0 x !llvm.double : (!llvm.i32) -> !llvm<"double*">
// CHECK-NEXT: %14 = llvm.getelementptr %13[%arg0, %arg0] : (!llvm<"double*">, !llvm.i32, !llvm.i32) -> !llvm<"double*">
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-03 06:33:54 +08:00
// CHECK-NEXT: %15 = llvm.load %14 : !llvm<"double*">
// CHECK-NEXT: llvm.store %15, %13 : !llvm<"double*">
// CHECK-NEXT: %16 = llvm.bitcast %13 : !llvm<"double*"> to !llvm<"i64*">
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-06 14:56:49 +08:00
%13 = llvm.alloca %arg0 x !llvm.double : (!llvm.i32) -> !llvm<"double*">
%14 = llvm.getelementptr %13[%arg0, %arg0] : (!llvm<"double*">, !llvm.i32, !llvm.i32) -> !llvm<"double*">
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-03 06:33:54 +08:00
%15 = llvm.load %14 : !llvm<"double*">
llvm.store %15, %13 : !llvm<"double*">
%16 = llvm.bitcast %13 : !llvm<"double*"> to !llvm<"i64*">
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
Replace remaining usages of the Instruction class with Operation. PiperOrigin-RevId: 240777521
2019-03-28 23:24:38 +08:00
// Function call-related operations.
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
//
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-06 14:56:49 +08:00
// CHECK-NEXT: %17 = llvm.call @foo(%arg0) : (!llvm.i32) -> !llvm<"{ i32, double, i32 }">
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-03 06:33:54 +08:00
// CHECK-NEXT: %18 = llvm.extractvalue %17[0] : !llvm<"{ i32, double, i32 }">
// CHECK-NEXT: %19 = llvm.insertvalue %18, %17[2] : !llvm<"{ i32, double, i32 }">
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-04 00:10:24 +08:00
// CHECK-NEXT: %20 = llvm.mlir.constant(@foo) : !llvm<"{ i32, double, i32 } (i32)*">
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-06 14:56:49 +08:00
// CHECK-NEXT: %21 = llvm.call %20(%arg0) : (!llvm.i32) -> !llvm<"{ i32, double, i32 }">
%17 = llvm.call @foo(%arg0) : (!llvm.i32) -> !llvm<"{ i32, double, i32 }">
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-03 06:33:54 +08:00
%18 = llvm.extractvalue %17[0] : !llvm<"{ i32, double, i32 }">
%19 = llvm.insertvalue %18, %17[2] : !llvm<"{ i32, double, i32 }">
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-04 00:10:24 +08:00
%20 = llvm.mlir.constant(@foo) : !llvm<"{ i32, double, i32 } (i32)*">
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-06 14:56:49 +08:00
%21 = llvm.call %20(%arg0) : (!llvm.i32) -> !llvm<"{ i32, double, i32 }">
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-03 06:33:54 +08:00
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
Replace remaining usages of the Instruction class with Operation. PiperOrigin-RevId: 240777521
2019-03-28 23:24:38 +08:00
// Terminator operations and their successors.
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
//
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-03 06:33:54 +08:00
// CHECK: llvm.br ^bb1
llvm.br ^bb1
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
^bb1:
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-03 06:33:54 +08:00
// CHECK: llvm.cond_br %7, ^bb2, ^bb1
llvm.cond_br %7, ^bb2, ^bb1
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
^bb2:
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-04 00:10:24 +08:00
// CHECK: %22 = llvm.mlir.undef : !llvm<"{ i32, double, i32 }">
// CHECK-NEXT: %23 = llvm.mlir.constant(42 : i64) : !llvm.i47
%22 = llvm.mlir.undef : !llvm<"{ i32, double, i32 }">
%23 = llvm.mlir.constant(42) : !llvm.i47
LLVM IR Dialect: add select op and lower standard select to it This is a similar one-to-one mapping. PiperOrigin-RevId: 233621006
2019-02-13 01:31:20 +08:00
Replace remaining usages of the Instruction class with Operation. PiperOrigin-RevId: 240777521
2019-03-28 23:24:38 +08:00
// Misc operations.
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-06 14:56:49 +08:00
// CHECK: %24 = llvm.select %7, %0, %1 : !llvm.i1, !llvm.i32
%24 = llvm.select %7, %0, %1 : !llvm.i1, !llvm.i32
Add LLVM::IntToPtrOp and LLVM::PtrToIntOp to LLVM dialect. -- PiperOrigin-RevId: 249604199
2019-05-23 17:03:14 +08:00
// Integer to pointer and pointer to integer conversions.
//
// CHECK: %25 = llvm.inttoptr %arg0 : !llvm.i32 to !llvm<"i32*">
// CHECK-NEXT: %26 = llvm.ptrtoint %25 : !llvm<"i32*"> to !llvm.i32
%25 = llvm.inttoptr %arg0 : !llvm.i32 to !llvm<"i32*">
%26 = llvm.ptrtoint %25 : !llvm<"i32*"> to !llvm.i32
Add LLVM IR dialect hooks for FP128 and X86_FP80 types Closes tensorflow/mlir#184 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/184 from schweitzpgi:more-float-types ca27d00510a86ffc9c79c65fb3a0193b5ea097a0 PiperOrigin-RevId: 274288813
2019-10-12 09:35:02 +08:00
// Extended and Quad floating point
//
Allow '_' when pretty printing dialect symbols '_' is used frequently enough as the separator of words in symbols. We should allow it in dialect symbols when considering pretty printing. Also updated LangRef.md regarding pretty form. PiperOrigin-RevId: 275312494
2019-10-18 03:23:47 +08:00
// CHECK: %27 = llvm.fpext %arg1 : !llvm.float to !llvm.x86_fp80
Add LLVM IR dialect hooks for FP128 and X86_FP80 types Closes tensorflow/mlir#184 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/184 from schweitzpgi:more-float-types ca27d00510a86ffc9c79c65fb3a0193b5ea097a0 PiperOrigin-RevId: 274288813
2019-10-12 09:35:02 +08:00
// CHECK-NEXT: %28 = llvm.fpext %arg1 : !llvm.float to !llvm.fp128
Allow '_' when pretty printing dialect symbols '_' is used frequently enough as the separator of words in symbols. We should allow it in dialect symbols when considering pretty printing. Also updated LangRef.md regarding pretty form. PiperOrigin-RevId: 275312494
2019-10-18 03:23:47 +08:00
%27 = llvm.fpext %arg1 : !llvm.float to !llvm.x86_fp80
Add LLVM IR dialect hooks for FP128 and X86_FP80 types Closes tensorflow/mlir#184 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/184 from schweitzpgi:more-float-types ca27d00510a86ffc9c79c65fb3a0193b5ea097a0 PiperOrigin-RevId: 274288813
2019-10-12 09:35:02 +08:00
%28 = llvm.fpext %arg1 : !llvm.float to !llvm.fp128
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 15:39:25 +08:00
// CHECK: %29 = llvm.fneg %arg1 : !llvm.float
%29 = llvm.fneg %arg1 : !llvm.float
Add LLVM::IntToPtrOp and LLVM::PtrToIntOp to LLVM dialect. -- PiperOrigin-RevId: 249604199
2019-05-23 17:03:14 +08:00
// CHECK: llvm.return
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-03 06:33:54 +08:00
llvm.return
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
}
// An larger self-contained function.
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-06 14:56:49 +08:00
// CHECK-LABEL:func @foo(%arg0: !llvm.i32) -> !llvm<"{ i32, double, i32 }"> {
func @foo(%arg0: !llvm.i32) -> !llvm<"{ i32, double, i32 }"> {
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-04 00:10:24 +08:00
// CHECK-NEXT: %0 = llvm.mlir.constant(3 : i64) : !llvm.i32
// CHECK-NEXT: %1 = llvm.mlir.constant(3 : i64) : !llvm.i32
// CHECK-NEXT: %2 = llvm.mlir.constant(4.200000e+01 : f64) : !llvm.double
// CHECK-NEXT: %3 = llvm.mlir.constant(4.200000e+01 : f64) : !llvm.double
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-06 14:56:49 +08:00
// CHECK-NEXT: %4 = llvm.add %0, %1 : !llvm.i32
// CHECK-NEXT: %5 = llvm.mul %4, %1 : !llvm.i32
// CHECK-NEXT: %6 = llvm.fadd %2, %3 : !llvm.double
// CHECK-NEXT: %7 = llvm.fsub %3, %6 : !llvm.double
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-04 00:10:24 +08:00
// CHECK-NEXT: %8 = llvm.mlir.constant(1 : i64) : !llvm.i1
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-06 14:56:49 +08:00
// CHECK-NEXT: llvm.cond_br %8, ^bb1(%4 : !llvm.i32), ^bb2(%4 : !llvm.i32)
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-04 00:10:24 +08:00
%0 = llvm.mlir.constant(3) : !llvm.i32
%1 = llvm.mlir.constant(3) : !llvm.i32
%2 = llvm.mlir.constant(4.200000e+01) : !llvm.double
%3 = llvm.mlir.constant(4.200000e+01) : !llvm.double
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-06 14:56:49 +08:00
%4 = llvm.add %0, %1 : !llvm.i32
%5 = llvm.mul %4, %1 : !llvm.i32
%6 = llvm.fadd %2, %3 : !llvm.double
%7 = llvm.fsub %3, %6 : !llvm.double
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-04 00:10:24 +08:00
%8 = llvm.mlir.constant(1) : !llvm.i1
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-06 14:56:49 +08:00
llvm.cond_br %8, ^bb1(%4 : !llvm.i32), ^bb2(%4 : !llvm.i32)
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-03 06:33:54 +08:00
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-06 14:56:49 +08:00
// CHECK-NEXT:^bb1(%9: !llvm.i32):
// CHECK-NEXT: %10 = llvm.call @foo(%9) : (!llvm.i32) -> !llvm<"{ i32, double, i32 }">
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-03 06:33:54 +08:00
// CHECK-NEXT: %11 = llvm.extractvalue %10[0] : !llvm<"{ i32, double, i32 }">
// CHECK-NEXT: %12 = llvm.extractvalue %10[1] : !llvm<"{ i32, double, i32 }">
// CHECK-NEXT: %13 = llvm.extractvalue %10[2] : !llvm<"{ i32, double, i32 }">
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-04 00:10:24 +08:00
// CHECK-NEXT: %14 = llvm.mlir.undef : !llvm<"{ i32, double, i32 }">
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-03 06:33:54 +08:00
// CHECK-NEXT: %15 = llvm.insertvalue %5, %14[0] : !llvm<"{ i32, double, i32 }">
// CHECK-NEXT: %16 = llvm.insertvalue %7, %15[1] : !llvm<"{ i32, double, i32 }">
// CHECK-NEXT: %17 = llvm.insertvalue %11, %16[2] : !llvm<"{ i32, double, i32 }">
// CHECK-NEXT: llvm.return %17 : !llvm<"{ i32, double, i32 }">
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-06 14:56:49 +08:00
^bb1(%9: !llvm.i32):
%10 = llvm.call @foo(%9) : (!llvm.i32) -> !llvm<"{ i32, double, i32 }">
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-03 06:33:54 +08:00
%11 = llvm.extractvalue %10[0] : !llvm<"{ i32, double, i32 }">
%12 = llvm.extractvalue %10[1] : !llvm<"{ i32, double, i32 }">
%13 = llvm.extractvalue %10[2] : !llvm<"{ i32, double, i32 }">
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-04 00:10:24 +08:00
%14 = llvm.mlir.undef : !llvm<"{ i32, double, i32 }">
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-03 06:33:54 +08:00
%15 = llvm.insertvalue %5, %14[0] : !llvm<"{ i32, double, i32 }">
%16 = llvm.insertvalue %7, %15[1] : !llvm<"{ i32, double, i32 }">
%17 = llvm.insertvalue %11, %16[2] : !llvm<"{ i32, double, i32 }">
llvm.return %17 : !llvm<"{ i32, double, i32 }">
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-06 14:56:49 +08:00
// CHECK-NEXT:^bb2(%18: !llvm.i32): // pred: ^bb0
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-04 00:10:24 +08:00
// CHECK-NEXT: %19 = llvm.mlir.undef : !llvm<"{ i32, double, i32 }">
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-03 06:33:54 +08:00
// CHECK-NEXT: %20 = llvm.insertvalue %18, %19[0] : !llvm<"{ i32, double, i32 }">
// CHECK-NEXT: %21 = llvm.insertvalue %7, %20[1] : !llvm<"{ i32, double, i32 }">
// CHECK-NEXT: %22 = llvm.insertvalue %5, %21[2] : !llvm<"{ i32, double, i32 }">
// CHECK-NEXT: llvm.return %22 : !llvm<"{ i32, double, i32 }">
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-06 14:56:49 +08:00
^bb2(%18: !llvm.i32): // pred: ^bb0
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-04 00:10:24 +08:00
%19 = llvm.mlir.undef : !llvm<"{ i32, double, i32 }">
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-03 06:33:54 +08:00
%20 = llvm.insertvalue %18, %19[0] : !llvm<"{ i32, double, i32 }">
%21 = llvm.insertvalue %7, %20[1] : !llvm<"{ i32, double, i32 }">
%22 = llvm.insertvalue %5, %21[2] : !llvm<"{ i32, double, i32 }">
llvm.return %22 : !llvm<"{ i32, double, i32 }">
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
}
Introduce std.index_cast and its lowering+translation to LLVM Index types integers of platform-specific bit width. They are used to index memrefs and as loop induction variables, however they could not be obtained from an integer until now, making it virtually impossible to express indirect accesses (given that memrefs of indices are not allowed) or data-dependent loops. Introduce `std.index_cast` to transform indices into integers and vice versa. The semantics of this cast is to sign-extend when casting to a wider integer, and to truncate when casting to a narrower integer. It belongs to StandardOps because both types it operates on are standard types, and because its results are likely to be used in std.load and std.store. Introduce llvm.sext, llvm.zext and llvm.trunc operations to the LLVM dialect. Provide the conversion of `std.index_cast` to llvm.sext or llvm.trunc, depending on the actual bitwidth of `index` known during the conversion. PiperOrigin-RevId: 253624100
2019-06-18 02:35:05 +08:00
// CHECK-LABEL: @casts
func @casts(%arg0: !llvm.i32, %arg1: !llvm.i64, %arg2: !llvm<"<4 x i32>">,
[mlir][llvm] Add missing cast ops Also adds a builder method for fcmp, identical to that for icmp. PiperOrigin-RevId: 277923158
2019-11-01 22:31:33 +08:00
%arg3: !llvm<"<4 x i64>">, %arg4: !llvm<"i32*">) {
Introduce std.index_cast and its lowering+translation to LLVM Index types integers of platform-specific bit width. They are used to index memrefs and as loop induction variables, however they could not be obtained from an integer until now, making it virtually impossible to express indirect accesses (given that memrefs of indices are not allowed) or data-dependent loops. Introduce `std.index_cast` to transform indices into integers and vice versa. The semantics of this cast is to sign-extend when casting to a wider integer, and to truncate when casting to a narrower integer. It belongs to StandardOps because both types it operates on are standard types, and because its results are likely to be used in std.load and std.store. Introduce llvm.sext, llvm.zext and llvm.trunc operations to the LLVM dialect. Provide the conversion of `std.index_cast` to llvm.sext or llvm.trunc, depending on the actual bitwidth of `index` known during the conversion. PiperOrigin-RevId: 253624100
2019-06-18 02:35:05 +08:00
// CHECK-NEXT: = llvm.sext %arg0 : !llvm.i32 to !llvm.i56
%0 = llvm.sext %arg0 : !llvm.i32 to !llvm.i56
// CHECK-NEXT: = llvm.zext %arg0 : !llvm.i32 to !llvm.i64
%1 = llvm.zext %arg0 : !llvm.i32 to !llvm.i64
// CHECK-NEXT: = llvm.trunc %arg1 : !llvm.i64 to !llvm.i56
%2 = llvm.trunc %arg1 : !llvm.i64 to !llvm.i56
// CHECK-NEXT: = llvm.sext %arg2 : !llvm<"<4 x i32>"> to !llvm<"<4 x i56>">
%3 = llvm.sext %arg2 : !llvm<"<4 x i32>"> to !llvm<"<4 x i56>">
// CHECK-NEXT: = llvm.zext %arg2 : !llvm<"<4 x i32>"> to !llvm<"<4 x i64>">
%4 = llvm.zext %arg2 : !llvm<"<4 x i32>"> to !llvm<"<4 x i64>">
// CHECK-NEXT: = llvm.trunc %arg3 : !llvm<"<4 x i64>"> to !llvm<"<4 x i56>">
%5 = llvm.trunc %arg3 : !llvm<"<4 x i64>"> to !llvm<"<4 x i56>">
[mlir][llvm] Add missing cast ops Also adds a builder method for fcmp, identical to that for icmp. PiperOrigin-RevId: 277923158
2019-11-01 22:31:33 +08:00
// CHECK-NEXT: = llvm.sitofp %arg0 : !llvm.i32 to !llvm.float
%6 = llvm.sitofp %arg0 : !llvm.i32 to !llvm.float
// CHECK-NEXT: = llvm.uitofp %arg0 : !llvm.i32 to !llvm.float
%7 = llvm.uitofp %arg0 : !llvm.i32 to !llvm.float
// CHECK-NEXT: = llvm.fptosi %7 : !llvm.float to !llvm.i32
%8 = llvm.fptosi %7 : !llvm.float to !llvm.i32
// CHECK-NEXT: = llvm.fptoui %7 : !llvm.float to !llvm.i32
%9 = llvm.fptoui %7 : !llvm.float to !llvm.i32
// CHECK-NEXT: = llvm.addrspacecast %arg4 : !llvm<"i32*"> to !llvm<"i32 addrspace(2)*">
%10 = llvm.addrspacecast %arg4 : !llvm<"i32*"> to !llvm<"i32 addrspace(2)*">
Introduce std.index_cast and its lowering+translation to LLVM Index types integers of platform-specific bit width. They are used to index memrefs and as loop induction variables, however they could not be obtained from an integer until now, making it virtually impossible to express indirect accesses (given that memrefs of indices are not allowed) or data-dependent loops. Introduce `std.index_cast` to transform indices into integers and vice versa. The semantics of this cast is to sign-extend when casting to a wider integer, and to truncate when casting to a narrower integer. It belongs to StandardOps because both types it operates on are standard types, and because its results are likely to be used in std.load and std.store. Introduce llvm.sext, llvm.zext and llvm.trunc operations to the LLVM dialect. Provide the conversion of `std.index_cast` to llvm.sext or llvm.trunc, depending on the actual bitwidth of `index` known during the conversion. PiperOrigin-RevId: 253624100
2019-06-18 02:35:05 +08:00
llvm.return
}
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 20:24:47 +08:00
// CHECK-LABEL: @vect
func @vect(%arg0: !llvm<"<4 x float>">, %arg1: !llvm.i32, %arg2: !llvm.float) {
// CHECK-NEXT: = llvm.extractelement {{.*}} : !llvm<"<4 x float>">
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-26 06:44:20 +08:00
%0 = llvm.extractelement %arg0[%arg1 : !llvm.i32] : !llvm<"<4 x float>">
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 20:24:47 +08:00
// CHECK-NEXT: = llvm.insertelement {{.*}} : !llvm<"<4 x float>">
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-26 06:44:20 +08:00
%1 = llvm.insertelement %arg2, %arg0[%arg1 : !llvm.i32] : !llvm<"<4 x float>">
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 20:24:47 +08:00
// CHECK-NEXT: = llvm.shufflevector {{.*}} [0 : i32, 0 : i32, 0 : i32, 0 : i32, 7 : i32] : !llvm<"<4 x float>">, !llvm<"<4 x float>">
%2 = llvm.shufflevector %arg0, %arg0 [0 : i32, 0 : i32, 0 : i32, 0 : i32, 7 : i32] : !llvm<"<4 x float>">, !llvm<"<4 x float>">
Update the syntax of splat attribute in LLVM.md The syntax for splat attributes changed, but was not updated in the description of the LLVM dialect constant operations in LLVM.md. Update the document to use the correct syntax. Also add a dialect roundtrip test for such attribute, which was previously missing. PiperOrigin-RevId: 267116305
2019-09-04 18:01:17 +08:00
// CHECK-NEXT: = llvm.mlir.constant(dense<1.000000e+00> : vector<4xf32>) : !llvm<"<4 x float>">
%3 = llvm.mlir.constant(dense<1.0> : vector<4xf32>) : !llvm<"<4 x float>">
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 20:24:47 +08:00
return
}
Add alignment support for llvm.alloca Extend the LLVM dialect AllocaOp with an alignment attribute. PiperOrigin-RevId: 264068306
2019-08-19 09:54:50 +08:00
// CHECK-LABEL: @alloca
func @alloca(%size : !llvm.i64) {
// CHECK: llvm.alloca %{{.*}} x !llvm.i32 : (!llvm.i64) -> !llvm<"i32*">
llvm.alloca %size x !llvm.i32 {alignment = 0} : (!llvm.i64) -> (!llvm<"i32*">)
// CHECK-NEXT: llvm.alloca %{{.*}} x !llvm.i32 {alignment = 8 : i64} : (!llvm.i64) -> !llvm<"i32*">
llvm.alloca %size x !llvm.i32 {alignment = 8} : (!llvm.i64) -> (!llvm<"i32*">)
llvm.return
}
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 21:13:25 +08:00
// CHECK-LABEL: @null
func @null() {
// CHECK: llvm.mlir.null : !llvm<"i8*">
%0 = llvm.mlir.null : !llvm<"i8*">
// CHECK: llvm.mlir.null : !llvm<"{ void (i32, void ()*)*, i64 }*">
%1 = llvm.mlir.null : !llvm<"{void(i32, void()*)*, i64}*">
llvm.return
}
[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-18 04:09:53 +08:00
[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 16:22:01 +08:00
// CHECK-LABEL: @atomicrmw
func @atomicrmw(%ptr : !llvm<"float*">, %val : !llvm.float) {
// CHECK: llvm.atomicrmw fadd %{{.*}}, %{{.*}} unordered : !llvm.float
%0 = llvm.atomicrmw fadd %ptr, %val unordered : !llvm.float
llvm.return
}
// CHECK-LABEL: @cmpxchg
func @cmpxchg(%ptr : !llvm<"float*">, %cmp : !llvm.float, %new : !llvm.float) {
// CHECK: llvm.cmpxchg %{{.*}}, %{{.*}}, %{{.*}} acq_rel monotonic : !llvm.float
%0 = llvm.cmpxchg %ptr, %cmp, %new acq_rel monotonic : !llvm.float
[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-18 04:09:53 +08:00
llvm.return
}
[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 (https://github.com/llvm/llvm-project/blob/4f82af81a04d711721300f6ca32f402f2ea6faf4/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 19:50:12 +08:00
llvm.mlir.global external constant @_ZTIi() : !llvm<"i8*">
llvm.func @bar(!llvm<"i8*">, !llvm<"i8*">, !llvm<"i8*">)
llvm.func @__gxx_personality_v0(...) -> !llvm.i32
// CHECK-LABEL: @invokeLandingpad
llvm.func @invokeLandingpad() -> !llvm.i32 {
// CHECK-NEXT: %[[a0:[0-9]+]] = llvm.mlir.constant(0 : i32) : !llvm.i32
// CHECK-NEXT: %{{[0-9]+}} = llvm.mlir.constant(3 : i32) : !llvm.i32
// CHECK-NEXT: %[[a2:[0-9]+]] = llvm.mlir.constant("\01") : !llvm<"[1 x i8]">
// CHECK-NEXT: %[[a3:[0-9]+]] = llvm.mlir.null : !llvm<"i8**">
// CHECK-NEXT: %[[a4:[0-9]+]] = llvm.mlir.null : !llvm<"i8*">
// CHECK-NEXT: %[[a5:[0-9]+]] = llvm.mlir.addressof @_ZTIi : !llvm<"i8**">
// CHECK-NEXT: %[[a6:[0-9]+]] = llvm.bitcast %[[a5]] : !llvm<"i8**"> to !llvm<"i8*">
// CHECK-NEXT: %[[a7:[0-9]+]] = llvm.mlir.constant(1 : i32) : !llvm.i32
// CHECK-NEXT: %[[a8:[0-9]+]] = llvm.alloca %[[a7]] x !llvm.i8 : (!llvm.i32) -> !llvm<"i8*">
// CHECK-NEXT: %{{[0-9]+}} = llvm.invoke @foo(%[[a7]]) to ^bb2 unwind ^bb1 : (!llvm.i32) -> !llvm<"{ i32, double, i32 }">
%0 = llvm.mlir.constant(0 : i32) : !llvm.i32
%1 = llvm.mlir.constant(3 : i32) : !llvm.i32
%2 = llvm.mlir.constant("\01") : !llvm<"[1 x i8]">
%3 = llvm.mlir.null : !llvm<"i8**">
%4 = llvm.mlir.null : !llvm<"i8*">
%5 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**">
%6 = llvm.bitcast %5 : !llvm<"i8**"> to !llvm<"i8*">
%7 = llvm.mlir.constant(1 : i32) : !llvm.i32
%8 = llvm.alloca %7 x !llvm.i8 : (!llvm.i32) -> !llvm<"i8*">
%9 = llvm.invoke @foo(%7) to ^bb2 unwind ^bb1 : (!llvm.i32) -> !llvm<"{ i32, double, i32 }">
// CHECK-NEXT: ^bb1:
// CHECK-NEXT: %{{[0-9]+}} = llvm.landingpad cleanup (catch %[[a3]] : !llvm<"i8**">) (catch %[[a6]] : !llvm<"i8*">) (filter %[[a2]] : !llvm<"[1 x i8]">) : !llvm<"{ i8*, i32 }">
// CHECK-NEXT: llvm.br ^bb3
^bb1:
%10 = llvm.landingpad cleanup (catch %3 : !llvm<"i8**">) (catch %6 : !llvm<"i8*">) (filter %2 : !llvm<"[1 x i8]">) : !llvm<"{ i8*, i32 }">
llvm.br ^bb3
// CHECK-NEXT: ^bb2:
// CHECK-NEXT: llvm.return %[[a7]] : !llvm.i32
^bb2:
llvm.return %7 : !llvm.i32
// CHECK-NEXT: ^bb3:
// CHECK-NEXT: llvm.invoke @bar(%[[a8]], %[[a6]], %[[a4]]) to ^bb2 unwind ^bb1 : (!llvm<"i8*">, !llvm<"i8*">, !llvm<"i8*">) -> ()
^bb3:
llvm.invoke @bar(%8, %6, %4) to ^bb2 unwind ^bb1 : (!llvm<"i8*">, !llvm<"i8*">, !llvm<"i8*">) -> ()
// CHECK-NEXT: ^bb4:
// CHECK-NEXT: llvm.return %[[a0]] : !llvm.i32
^bb4:
llvm.return %0 : !llvm.i32
}
[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 17:19:57 +08:00
// CHECK-LABEL: @useFreezeOp
func @useFreezeOp(%arg0: !llvm.i32) {
// CHECK: = llvm.freeze %[[ARG0:.*]] : !llvm.i32
%0 = llvm.freeze %arg0 : !llvm.i32
// CHECK: %[[x:.*]] = llvm.mlir.undef : !llvm.i8
%1 = llvm.mlir.undef : !llvm.i8
// CHECK: = llvm.freeze %[[x]] : !llvm.i8
%2 = llvm.freeze %1 : !llvm.i8
return
[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-18 00:43:21 +08:00
}
// CHECK-LABEL: @useFenceInst
func @useFenceInst() {
// CHECK: syncscope("agent") seq_cst
llvm.fence syncscope("agent") seq_cst
// CHECK: seq_cst
llvm.fence syncscope("") seq_cst
// CHECK: release
llvm.fence release
return
[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 17:19:57 +08:00
}