Skip to content

Conversation

jacquesguan
Copy link
Contributor

No description provided.

@llvmbot
Copy link
Member

llvmbot commented Aug 23, 2024

@llvm/pr-subscribers-mlir

@llvm/pr-subscribers-mlir-emitc

Author: Jianjian Guan (jacquesguan)

Changes

Full diff: https://github.com/llvm/llvm-project/pull/105803.diff

5 Files Affected:

  • (modified) mlir/lib/Dialect/EmitC/IR/EmitC.cpp (+1)
  • (modified) mlir/lib/Target/Cpp/TranslateToCpp.cpp (+5)
  • (modified) mlir/test/Conversion/ArithToEmitC/arith-to-emitc-unsupported.mlir (-33)
  • (modified) mlir/test/Conversion/MemRefToEmitC/memref-to-emitc-failed.mlir (-8)
  • (modified) mlir/test/Target/Cpp/types.mlir (+4)
diff --git a/mlir/lib/Dialect/EmitC/IR/EmitC.cpp b/mlir/lib/Dialect/EmitC/IR/EmitC.cpp
index e6f1618cc26116..8555e82002d56b 100644
--- a/mlir/lib/Dialect/EmitC/IR/EmitC.cpp
+++ b/mlir/lib/Dialect/EmitC/IR/EmitC.cpp
@@ -116,6 +116,7 @@ bool mlir::emitc::isIntegerIndexOrOpaqueType(Type type) {
 bool mlir::emitc::isSupportedFloatType(Type type) {
   if (auto floatType = llvm::dyn_cast<FloatType>(type)) {
     switch (floatType.getWidth()) {
+    case 16:
     case 32:
     case 64:
       return true;
diff --git a/mlir/lib/Target/Cpp/TranslateToCpp.cpp b/mlir/lib/Target/Cpp/TranslateToCpp.cpp
index c043582b7be9c6..aa45e7c9d7f757 100644
--- a/mlir/lib/Target/Cpp/TranslateToCpp.cpp
+++ b/mlir/lib/Target/Cpp/TranslateToCpp.cpp
@@ -1640,6 +1640,11 @@ LogicalResult CppEmitter::emitType(Location loc, Type type) {
   }
   if (auto fType = dyn_cast<FloatType>(type)) {
     switch (fType.getWidth()) {
+    case 16:
+      if (llvm::isa<Float16Type>(type))
+        return (os << "_Float16"), success();
+      else
+        return (os << "__bf16"), success();
     case 32:
       return (os << "float"), success();
     case 64:
diff --git a/mlir/test/Conversion/ArithToEmitC/arith-to-emitc-unsupported.mlir b/mlir/test/Conversion/ArithToEmitC/arith-to-emitc-unsupported.mlir
index ef0e71ee8673b7..b3eebaf8a1ef1e 100644
--- a/mlir/test/Conversion/ArithToEmitC/arith-to-emitc-unsupported.mlir
+++ b/mlir/test/Conversion/ArithToEmitC/arith-to-emitc-unsupported.mlir
@@ -16,39 +16,6 @@ func.func @arith_cast_vector(%arg0: vector<5xf32>) -> vector<5xi32> {
 
 // -----
 
-func.func @arith_cast_bf16(%arg0: bf16) -> i32 {
-  // expected-error @+1 {{failed to legalize operation 'arith.fptosi'}}
-  %t = arith.fptosi %arg0 : bf16 to i32
-  return %t: i32
-}
-
-// -----
-
-func.func @arith_cast_f16(%arg0: f16) -> i32 {
-  // expected-error @+1 {{failed to legalize operation 'arith.fptosi'}}
-  %t = arith.fptosi %arg0 : f16 to i32
-  return %t: i32
-}
-
-
-// -----
-
-func.func @arith_cast_to_bf16(%arg0: i32) -> bf16 {
-  // expected-error @+1 {{failed to legalize operation 'arith.sitofp'}}
-  %t = arith.sitofp %arg0 : i32 to bf16
-  return %t: bf16
-}
-
-// -----
-
-func.func @arith_cast_to_f16(%arg0: i32) -> f16 {
-  // expected-error @+1 {{failed to legalize operation 'arith.sitofp'}}
-  %t = arith.sitofp %arg0 : i32 to f16
-  return %t: f16
-}
-
-// -----
-
 func.func @arith_cast_fptosi_i1(%arg0: f32) -> i1 {
   // expected-error @+1 {{failed to legalize operation 'arith.fptosi'}}
   %t = arith.fptosi %arg0 : f32 to i1
diff --git a/mlir/test/Conversion/MemRefToEmitC/memref-to-emitc-failed.mlir b/mlir/test/Conversion/MemRefToEmitC/memref-to-emitc-failed.mlir
index 836d8aedefc1f0..14977bfb3e2fd9 100644
--- a/mlir/test/Conversion/MemRefToEmitC/memref-to-emitc-failed.mlir
+++ b/mlir/test/Conversion/MemRefToEmitC/memref-to-emitc-failed.mlir
@@ -46,14 +46,6 @@ memref.global "nested" constant @nested_global : memref<3x7xf32>
 
 // -----
 
-func.func @unsupported_type_f16() {
-  // expected-error@+1 {{failed to legalize operation 'memref.alloca'}}
-  %0 = memref.alloca() : memref<4xf16>
-  return
-}
-
-// -----
-
 func.func @unsupported_type_i4() {
   // expected-error@+1 {{failed to legalize operation 'memref.alloca'}}
   %0 = memref.alloca() : memref<4xi4>
diff --git a/mlir/test/Target/Cpp/types.mlir b/mlir/test/Target/Cpp/types.mlir
index deda383b3b0a72..e7f935c7374382 100644
--- a/mlir/test/Target/Cpp/types.mlir
+++ b/mlir/test/Target/Cpp/types.mlir
@@ -22,6 +22,10 @@ func.func @ptr_types() {
   emitc.call_opaque "f"() {template_args = [!emitc.ptr<i32>]} : () -> ()
   // CHECK-NEXT: f<int64_t*>();
   emitc.call_opaque "f"() {template_args = [!emitc.ptr<i64>]} : () -> ()
+  // CHECK-NEXT: f<_Float16*>();
+  emitc.call_opaque "f"() {template_args = [!emitc.ptr<f16>]} : () -> ()
+  // CHECK-NEXT: f<__bf16*>();
+  emitc.call_opaque "f"() {template_args = [!emitc.ptr<bf16>]} : () -> ()
   // CHECK-NEXT: f<float*>();
   emitc.call_opaque "f"() {template_args = [!emitc.ptr<f32>]} : () -> ()
   // CHECK-NEXT: f<double*>();

case 16:
if (llvm::isa<Float16Type>(type))
return (os << "_Float16"), success();
else
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please explicitly check for bfloat16; at the pace of current floating point development, I wouldn't be surprised if we get another 16 bit float type in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

bool mlir::emitc::isSupportedFloatType(Type type) {
if (auto floatType = llvm::dyn_cast<FloatType>(type)) {
switch (floatType.getWidth()) {
case 16:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please explicitly check for Float16Type and BFloat16Type here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@mgehre-amd
Copy link
Contributor

Thanks for your PR! Could you please update mlir/docs/Dialects/emitc.md to explain that f16/bf16 will require certain compiler extensions to consume the generated C++ code?

@mgehre-amd mgehre-amd requested a review from marbre August 23, 2024 09:09
@simon-camp
Copy link
Contributor

Can you please update the attribute emission to print the correct literal suffix: godbolt, clang documentation


// -----

func.func @arith_cast_bf16(%arg0: bf16) -> i32 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you keep the tests and replace the types with unsupported floating point types, like f128 and f80 (and tf32 is a thing as well, I think)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@jacquesguan jacquesguan force-pushed the mlir-support-f16-bf16 branch from 19f7d82 to 488bd12 Compare August 26, 2024 06:39
@jacquesguan
Copy link
Contributor Author

Can you please update the attribute emission to print the correct literal suffix: godbolt, clang documentation

Added fp16 and bf16 to the literal emit logic.

@jacquesguan
Copy link
Contributor Author

Thanks for your PR! Could you please update mlir/docs/Dialects/emitc.md to explain that f16/bf16 will require certain compiler extensions to consume the generated C++ code?

Add to the doc.

Copy link
Contributor

@cferry-AMD cferry-AMD left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One small nit, LGTM


// -----

func.func @unsupported_type_f16() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, keep the tests and replace the types with unsupported floating point types, like f128. But it's not that important. It's up to you.

Copy link
Member

@marbre marbre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Just two minor suggestions.

Comment on lines 17 to 18
* If `__bf16` is used, the code requires complier that supports it, such as:
GCC and Clang.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would probably rephrase to

Suggested change
* If `__bf16` is used, the code requires complier that supports it, such as:
GCC and Clang.
* If `__bf16` is used, the code requires a complier that supports it, such as
GCC or Clang.

@jacquesguan jacquesguan force-pushed the mlir-support-f16-bf16 branch from 488bd12 to d0adb5c Compare August 27, 2024 02:11
@jacquesguan
Copy link
Contributor Author

Thanks! Just two minor suggestions.

Thanks for comment, all addressed.

@CoTinker
Copy link
Contributor

LGTM!

or any of the C++ headers in which the type is defined.
* If `_Float16` is used, the code requires the support of C additional
floating types.
* If `__bf16` is used, the code requires a complier that supports it, such as
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* If `__bf16` is used, the code requires a complier that supports it, such as
* If `__bf16` is used, the code requires a compiler that supports it, such as

typo slipped through

Copy link
Member

@marbre marbre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, this look good to me. Please fix the typo as pointed to by @cferry-AMD. Beside this the PR should be ready to land. If you need assistance and someone who hits the Squash and merge button for you, let me know.

Copy link
Contributor

@TinaAMD TinaAMD left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small comment to the doc only, looks good to me otherwise!

Comment on lines +15 to +16
* If `_Float16` is used, the code requires the support of C additional
floating types.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think usually this documentation specifies the type in the mlir world and then relates it to something in C/C++. Maybe

If f16 types are used, the code requires a compiler that supports _Float16.

Same for bf16 below.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed

@jacquesguan jacquesguan force-pushed the mlir-support-f16-bf16 branch from d0adb5c to 5cd6285 Compare August 27, 2024 07:23
@jacquesguan jacquesguan merged commit d4f97da into llvm:main Aug 27, 2024
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants