[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs updated this revision to Diff 558083.
codemzs set the repository for this revision to rG LLVM Github Monorepo.
codemzs added a comment.

Synced to the main and resolved merge conflicts, updated tests.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Lex/LiteralSupport.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/SMTConv.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/Type.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Lex/LiteralSupport.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CodeGenCXX/cxx23-fp-ext-std-names-p1467r9.cpp
  clang/test/CodeGenCXX/cxx23-vector-bfloat16.cpp
  clang/test/Sema/cxx23-fp-ext-std-names-p1467r9.cpp

Index: clang/test/Sema/cxx23-fp-ext-std-names-p1467r9.cpp
===
--- /dev/null
+++ clang/test/Sema/cxx23-fp-ext-std-names-p1467r9.cpp
@@ -0,0 +1,465 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++23 -target-feature +fullbf16 -verify -ast-dump %s | FileCheck %s
+
+_Float16 f16_val_1 = 1.0bf16; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type '__bf16'}}
+_Float16 f16_val_2 = 1.0f; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type 'float'}}
+_Float16 f16_val_3 = 1.0; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type 'double'}}
+_Float16 f16_val_4 = 1.0l; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type 'long double'}}
+_Float16 f16_val_6 = 1.0f16;
+//CHECK:  VarDecl {{.*}} f16_val_6 '_Float16' cinit
+//CHECK-NEXT: FloatingLiteral {{.*}} '_Float16' 1.00e+00
+_Float16 f16_val_7 = static_cast<_Float16>(1.0bf16); // expected-error {{static_cast from '__bf16' to '_Float16' is not allowed}}
+_Float16 f16_val_8 = static_cast<_Float16>(1.0f);
+//CHECK:  VarDecl {{.*}} f16_val_8 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'float' 1.00e+00
+_Float16 f16_val_9 = static_cast<_Float16>(1.0);
+//CHECK:  VarDecl {{.*}} f16_val_9 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'double' 1.00e+00
+_Float16 f16_val_10 = static_cast<_Float16>(1.0l);
+//CHECK:  VarDecl {{.*}} f16_val_10 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'long double' 1.00e+00
+_Float16 f16_val_11 = static_cast<_Float16>(1.0f16);
+//CHECK:  VarDecl {{.*}} f16_val_11 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} '_Float16' 1.00e+00
+
+decltype(0.0BF16) bf16_val_1 = 1.0f16; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type '_Float16'}}
+decltype(0.0BF16) bf16_val_2 = 1.0f; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type 'float'}}
+decltype(0.0BF16) bf16_val_3 = 1.0; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type 'double'}}
+decltype(0.0BF16) bf16_val_4 = 1.0l; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type 'long double'}}
+decltype(0.0BF16) bf16_val_5 = 1.0bf16;
+//CHECK:  VarDecl {{.*}} bf16_val_5 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: FloatingLiteral {{.*}} '__bf16' 1.00e+00
+
+decltype(0.0BF16) bf16_val_6 = static_cast(1.0f16); // expected-error {{static_cast from '_Float16' to 'decltype(0.BF16)' (aka '__bf16') is not allowed}}
+decltype(0.0BF16) bf16_val_7 = static_cast(1.0f);
+//CHECK:  VarDecl {{.*}} bf16_val_7 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} 'decltype(0.BF16)':'__bf16' static_cast 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'float' 1.00e+00
+decltype(0.0BF16) bf16_val_8 = static_cast(1.0);
+//CHECK:  VarDecl {{.*}} bf16_val_8 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} 'decltype(0.BF16)':'__bf16' static_cast 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'double' 1.00e+00
+decltype(0.0BF16) bf16_val_9 = static_cast(1.0l);
+//CHECK:  VarDecl {{.*}} bf16_val_9 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} 'decltype(0.BF16)':'__bf16' static_cast 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'long double' 1.00e+00
+decltype(0.0BF16) bf1

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs updated this revision to Diff 558099.
codemzs added a comment.

Hi @tahonermann,

I've just pushed a new diff with tests for `va_arg` and `...`, ensuring 
promotion rules are intact.

Also, I've made sure `getFloatingTypeOrder` returns `FRCR_Unordered` only when 
we're dealing with both operands as C++23 extended floating point types and 
they are unordered. I've added tests like `_Float16 f16_val_1 = 1.0bf16; // 
expected-error {{cannot initialize a variable of type '_Float16' with an rvalue 
of type '__bf16'}}` to cover these cases. If you see any potential issues here, 
I'm all ears and ready to make adjustments.

Thanks a lot for reviewing this, especially with your busy schedule.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Lex/LiteralSupport.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/SMTConv.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/Type.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Lex/LiteralSupport.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CodeGenCXX/cxx23-fp-ext-std-names-p1467r9.cpp
  clang/test/CodeGenCXX/cxx23-vector-bfloat16.cpp
  clang/test/Sema/cxx23-fp-ext-std-names-p1467r9.cpp

Index: clang/test/Sema/cxx23-fp-ext-std-names-p1467r9.cpp
===
--- /dev/null
+++ clang/test/Sema/cxx23-fp-ext-std-names-p1467r9.cpp
@@ -0,0 +1,505 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++23 -target-feature +fullbf16 -verify -ast-dump %s | FileCheck %s
+#include 
+_Float16 f16_val_1 = 1.0bf16; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type '__bf16'}}
+_Float16 f16_val_2 = 1.0f; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type 'float'}}
+_Float16 f16_val_3 = 1.0; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type 'double'}}
+_Float16 f16_val_4 = 1.0l; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type 'long double'}}
+_Float16 f16_val_6 = 1.0f16;
+//CHECK:  VarDecl {{.*}} f16_val_6 '_Float16' cinit
+//CHECK-NEXT: FloatingLiteral {{.*}} '_Float16' 1.00e+00
+_Float16 f16_val_7 = static_cast<_Float16>(1.0bf16); // expected-error {{static_cast from '__bf16' to '_Float16' is not allowed}}
+_Float16 f16_val_8 = static_cast<_Float16>(1.0f);
+//CHECK:  VarDecl {{.*}} f16_val_8 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'float' 1.00e+00
+_Float16 f16_val_9 = static_cast<_Float16>(1.0);
+//CHECK:  VarDecl {{.*}} f16_val_9 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'double' 1.00e+00
+_Float16 f16_val_10 = static_cast<_Float16>(1.0l);
+//CHECK:  VarDecl {{.*}} f16_val_10 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'long double' 1.00e+00
+_Float16 f16_val_11 = static_cast<_Float16>(1.0f16);
+//CHECK:  VarDecl {{.*}} f16_val_11 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} '_Float16' 1.00e+00
+
+decltype(0.0BF16) bf16_val_1 = 1.0f16; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type '_Float16'}}
+decltype(0.0BF16) bf16_val_2 = 1.0f; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type 'float'}}
+decltype(0.0BF16) bf16_val_3 = 1.0; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type 'double'}}
+decltype(0.0BF16) bf16_val_4 = 1.0l; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type 'long double'}}
+decltype(0.0BF16) bf16_val_5 = 1.0bf16;
+//CHECK:  VarDecl {{.*}} bf16_val_5 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: FloatingLiteral {{.*}} '__bf16' 1.00e+00
+
+decltype(0.0BF16) bf16_val_6 = static_cast(1.0f16); // expected-error {{static_cast from '_Float16' to 'decltype(0.BF16)' (aka '__bf16') is not allowed}}
+decltype(0.0BF16) bf16_val_7 = static_cast(1.0f);
+//CHECK:  VarDecl {{.*}} bf16_val_7 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} 'decltype(0.BF16)':'__bf16' static_cast 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'float' 1.00e+00
+decltype(0.0BF16) bf16_val_8 = static_cast(1.0);
+//CHECK

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs updated this revision to Diff 546100.
codemzs marked an inline comment as done.
codemzs added a comment.

Updated with feedback from @tahonermann


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Lex/LiteralSupport.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/SMTConv.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/Type.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Lex/LiteralSupport.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CodeGenCXX/cxx23-fp-ext-std-names-p1467r9.cpp
  clang/test/CodeGenCXX/cxx23-vector-bfloat16.cpp
  clang/test/Sema/cxx23-fp-ext-std-names-p1467r9.cpp

Index: clang/test/Sema/cxx23-fp-ext-std-names-p1467r9.cpp
===
--- /dev/null
+++ clang/test/Sema/cxx23-fp-ext-std-names-p1467r9.cpp
@@ -0,0 +1,465 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++23 -target-feature +fullbf16 -verify -ast-dump %s | FileCheck %s
+
+_Float16 f16_val_1 = 1.0bf16; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type '__bf16'}}
+_Float16 f16_val_2 = 1.0f; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type 'float'}}
+_Float16 f16_val_3 = 1.0; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type 'double'}}
+_Float16 f16_val_4 = 1.0l; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type 'long double'}}
+_Float16 f16_val_6 = 1.0f16;
+//CHECK:  VarDecl {{.*}} f16_val_6 '_Float16' cinit
+//CHECK-NEXT: FloatingLiteral {{.*}} '_Float16' 1.00e+00
+_Float16 f16_val_7 = static_cast<_Float16>(1.0bf16); // expected-error {{static_cast from '__bf16' to '_Float16' is not allowed}}
+_Float16 f16_val_8 = static_cast<_Float16>(1.0f);
+//CHECK:  VarDecl {{.*}} f16_val_8 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'float' 1.00e+00
+_Float16 f16_val_9 = static_cast<_Float16>(1.0);
+//CHECK:  VarDecl {{.*}} f16_val_9 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'double' 1.00e+00
+_Float16 f16_val_10 = static_cast<_Float16>(1.0l);
+//CHECK:  VarDecl {{.*}} f16_val_10 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'long double' 1.00e+00
+_Float16 f16_val_11 = static_cast<_Float16>(1.0f16);
+//CHECK:  VarDecl {{.*}} f16_val_11 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} '_Float16' 1.00e+00
+
+decltype(0.0BF16) bf16_val_1 = 1.0f16; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type '_Float16'}}
+decltype(0.0BF16) bf16_val_2 = 1.0f; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type 'float'}}
+decltype(0.0BF16) bf16_val_3 = 1.0; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type 'double'}}
+decltype(0.0BF16) bf16_val_4 = 1.0l; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type 'long double'}}
+decltype(0.0BF16) bf16_val_5 = 1.0bf16;
+//CHECK:  VarDecl {{.*}} bf16_val_5 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: FloatingLiteral {{.*}} '__bf16' 1.00e+00
+
+decltype(0.0BF16) bf16_val_6 = static_cast(1.0f16); // expected-error {{static_cast from '_Float16' to 'decltype(0.BF16)' (aka '__bf16') is not allowed}}
+decltype(0.0BF16) bf16_val_7 = static_cast(1.0f);
+//CHECK:  VarDecl {{.*}} bf16_val_7 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} 'decltype(0.BF16)':'__bf16' static_cast 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'float' 1.00e+00
+decltype(0.0BF16) bf16_val_8 = static_cast(1.0);
+//CHECK:  VarDecl {{.*}} bf16_val_8 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} 'decltype(0.BF16)':'__bf16' static_cast 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'double' 1.00e+00
+decltype(0.0BF16) bf16_val_9 = static_cast(1.0l);
+//CHECK:  VarDecl {{.*}} bf16_val_9 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} 'decltype(0.BF16)':'__bf16' static_cast 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'long double' 1.00e+00
+decltype(0.0BF16) bf16_val_10 = static_cast(1.0bf16);
+//CHECK:  VarDecl {{.*}} bf16_val_10 'decltype(0.BF16)':

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs added a comment.

@tahonermann I would like to understand your concern better on unordered 
floating point types as the callers of `getFloatingTypeOrder` handle this 
result as per the C++23 proposal, for example there is a test case that 
exercises this scenario: _Float16 f16_val_1 = 1.0bf16; // expected-error 
{{cannot initialize a variable of type '_Float16' with an rvalue of type 
'__bf16'}}

Perhaps if you can please give me an example that further illustrates your 
concerns it would help me understand and assuage your concerns. Thank you.




Comment at: clang/lib/AST/ASTContext.cpp:191
+   FloatingRankCompareResult::FRCR_Greater,
+   FloatingRankCompareResult::FRCR_Equal;
+

tahonermann wrote:
> I just realized that none of these comparisons results in 
> `FRCR_Equal_Lesser_Subrank` or `FRCR_Equal_Greater_Subrank`. I guess those 
> won't actually be used until support for `std::float32_t` and 
> `std::float64_t` are added. That means that we don't have a way to test code 
> that performs subrank checks though.
That is correct, my plan was to add support for these types after this change 
is committed. 



Comment at: clang/lib/Frontend/InitPreprocessor.cpp:461
+  Builder.defineMacro("__STDCPP_FLOAT16_T__", "1");
+  Builder.defineMacro("__STDCPP_BFLOAT16_T__", "1");
+}

tahonermann wrote:
> Should the definition of `__STDCPP_BFLOAT16_T__` be conditional on something 
> like `Ctx.getTargetInfo().hasFullBFloat16Type()`?
Based on [our 
discussion](https://discourse.llvm.org/t/rfc-c-23-p1467r9-extended-floating-point-types-and-standard-names/70033/34?u=codemzs)
 on the RFC it was determined that representing `bfloat16` using `fp32` is ok 
as per the author of the proposal, in that case do you believe we should be 
making this macro conditional on the target natively supporting `bfloat16`?



Comment at: clang/lib/Sema/SemaChecking.cpp:10451
   return ICE->getCastKind() == CK_FloatingCast &&
- S.Context.getFloatingTypeOrder(From, To) < 0;
+ S.Context.getFloatingTypeOrder(From, To) == FRCR_Lesser;
 }

tahonermann wrote:
> I'm not sure this is right. If I understand correctly, the C++23 extended FP 
> types don't participate in argument promotions. Perhaps they should be 
> excluded here.
Rules for 
[promotion](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1467r9.html#promotion)
 are unchanged as per the proposal. This is just using the new enumeration to 
represent a smaller conversion rank. 



Comment at: clang/test/Sema/cxx23-fp-ext-std-names-p1467r9.cpp:3-6
+_Float16 f16_val_1 = 1.0bf16; // expected-error {{cannot initialize a variable 
of type '_Float16' with an rvalue of type '__bf16'}}
+_Float16 f16_val_2 = 1.0f; // expected-error {{cannot initialize a variable of 
type '_Float16' with an rvalue of type 'float'}}
+_Float16 f16_val_3 = 1.0; // expected-error {{cannot initialize a variable of 
type '_Float16' with an rvalue of type 'double'}}
+_Float16 f16_val_4 = 1.0l; // expected-error {{cannot initialize a variable of 
type '_Float16' with an rvalue of type 'long double'}}

tahonermann wrote:
> Are these errors correct? Since the source is a constant expression that 
> specifies a value that is within the representable range of the type, I think 
> these initializations are expected to be allowed.
I believe this should be an error unless my understanding is incorrect, below 
is what the proposal 
[says](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1467r9.html#implicit-constant)
 for constant expressions:

"A drawback of this part of the proposal is that constant values don’t get any 
special treatment. As a result, this code:

`std::float16_t x = 1.0;`

would be ill-formed. The constant 1.0 has type double, which cannot be 
implicitly converted to type std::float16_t, even though the value 1.0 can be 
represented exactly in both types. To compile, the code must have an explicit 
cast, or, preferably, use a literal suffix:
`std::float16_t x = 1.0f16;`
"



CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D150913: [Clang][Bfloat16] Upgrade __bf16 to arithmetic type, change mangling, and extend excess precision support.

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs marked an inline comment as done.
codemzs added a comment.

I believe I had updated the `__bf16` documentation in 
`/llvm-project/clang/docs/LanguageExtensions.rst`, but it appears to have been 
omitted in this patch. I assure you, I'll rectify this in the next iteration.




Comment at: clang/include/clang/AST/ASTContext.h:1102
   CanQualType HalfTy; // [OpenCL 6.1.1.1], ARM NEON
-  CanQualType BFloat16Ty;
+  CanQualType BFloat16Ty; // ISO/IEC/IEEE 60559.
   CanQualType Float16Ty; // C11 extension ISO/IEC TS 18661-3

pengfei wrote:
> Don't have a look at ISO/IEC/IEEE 60559, but I doubt BF16 is still not a IEEE 
> type for now.
You are correct, it isn't officially part of ISO/I standard but implements 
the properties specified by the standard I think, in any case I will remove the 
comment as it could be misleading.



Comment at: clang/lib/Basic/Targets/AMDGPU.h:121
   bool hasBFloat16Type() const override { return isAMDGCN(getTriple()); }
-  const char *getBFloat16Mangling() const override { return "u6__bf16"; };
+  const char *getBFloat16Mangling() const override { return "DF16b"; };
 

pengfei wrote:
> I think it's time to bring D139608 back with this patch :)
I'm inclined to establish a default value, overridden only for ARM, to avoid 
repetition. If there are no objections, I plan to implement this change in the 
next iteration.



Comment at: clang/lib/Basic/Targets/X86.cpp:381
 
 HasBFloat16 = SSELevel >= SSE2;
 

rjmccall wrote:
> pengfei wrote:
> > I'm not sure if I understand the meaning of `HasFullBFloat16`. If it is 
> > used for target that supports arithmetic `__bf16`, we should not use 
> > `+fullbf16` but always enable it for SSE2, i.e., `HasFullBFloat16 = 
> > SSELevel >= SSE2`. Because X86 GCC already supports arithmetic for `__bf16`.
> > 
> > If this is used in the way like `HasLegalHalfType`, we should enable it 
> > once we have a full BF16 ISA on X86. `fullbf16` doesn't make much sense to 
> > me.
> At the moment, we haven't done the work to emulate BFloat16 arithmetic in any 
> of the three ways we can do that: Clang doesn't promote it in IRGen, LLVM 
> doesn't promote it in legalization, and we don't have compiler-rt functions 
> for it.  If we emit these instructions, they'll just sail through LLVM and 
> fail in the backend.  So in the short term, we have to restrict this to 
> targets that directly support BFloat16 arithmetic in hardware, which doesn't 
> include x86.
> 
> Once we have that emulation support, I agree that the x86 targets should 
> enable this whenever they would enable `__bf16`.
@rjmccall, I concur and just wanted to confirm this change indeed intends to 
provide `BFloat16` emulation support, utilizing excess precision for promotion 
to `float`. The `HasFullBFloat16` switch is designed to determine excess 
precision support automatically when the hardware does not natively support 
`bfloat16` arithmetic.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150913/new/

https://reviews.llvm.org/D150913

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D150913: [Clang][Bfloat16] Upgrade __bf16 to arithmetic type, change mangling, and extend excess precision support.

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs updated this revision to Diff 524467.
codemzs marked 12 inline comments as done.
codemzs added a comment.

@pengfei, @zahiraam, I appreciate your feedback.

@pengfei, the `HasFullBFloat16` flag is primarily for identifying hardware with 
native `bfloat16` support to facilitate automatic excess precision support. I 
concur that since x86 possesses backend bfloat16 emulation (as noted in D126953 
), front-end emulation might not be 
necessary. The test's purpose was to provide coverage for this change. However, 
I am open to either removing it entirely or relocating it to a more suitable 
target as per your recommendation.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150913/new/

https://reviews.llvm.org/D150913

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/FPOptions.def
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Driver/Options.td
  clang/lib/AST/Type.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CodeGen/X86/avx512bf16-error.c
  clang/test/CodeGen/X86/bfloat-mangle.cpp
  clang/test/CodeGen/X86/bfloat16.cpp
  clang/test/CodeGen/X86/fexcess-precision-bfloat16.c
  clang/test/CodeGenCUDA/amdgpu-bf16.cu
  clang/test/CodeGenCUDA/bf16.cu
  clang/test/Driver/fexcess-precision.c
  clang/test/Sema/arm-bf16-forbidden-ops.c
  clang/test/Sema/arm-bf16-forbidden-ops.cpp
  clang/test/Sema/arm-bfloat.cpp
  clang/test/SemaCUDA/amdgpu-bf16.cu
  clang/test/SemaCUDA/bf16.cu

Index: clang/test/SemaCUDA/bf16.cu
===
--- clang/test/SemaCUDA/bf16.cu
+++ clang/test/SemaCUDA/bf16.cu
@@ -2,32 +2,32 @@
 // REQUIRES: x86-registered-target
 
 // RUN: %clang_cc1 "-triple" "x86_64-unknown-linux-gnu" "-aux-triple" "nvptx64-nvidia-cuda" \
-// RUN:"-target-cpu" "x86-64" -fsyntax-only -verify=scalar %s
+// RUN:"-target-cpu" "x86-64" -fsyntax-only -verify=scalar -Wno-unused %s
 // RUN: %clang_cc1 "-aux-triple" "x86_64-unknown-linux-gnu" "-triple" "nvptx64-nvidia-cuda" \
-// RUN:-fcuda-is-device "-aux-target-cpu" "x86-64" -fsyntax-only -verify=scalar %s
+// RUN:-fcuda-is-device "-aux-target-cpu" "x86-64" -fsyntax-only -verify=scalar -Wno-unused %s
 
 #include "Inputs/cuda.h"
 
 __device__ void test(bool b, __bf16 *out, __bf16 in) {
   __bf16 bf16 = in; // No error on using the type itself.
 
-  bf16 + bf16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
-  bf16 - bf16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
-  bf16 * bf16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
-  bf16 / bf16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
+  bf16 + bf16;
+  bf16 - bf16;
+  bf16 * bf16;
+  bf16 / bf16;
 
   __fp16 fp16;
 
-  bf16 + fp16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
-  fp16 + bf16; // scalar-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
-  bf16 - fp16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
-  fp16 - bf16; // scalar-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
-  bf16 * fp16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
-  fp16 * bf16; // scalar-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
-  bf16 / fp16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
-  fp16 / bf16; // scalar-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
+  bf16 + fp16;
+  fp16 + bf16;
+  bf16 - fp16;
+  fp16 - bf16;
+  bf16 * fp16;
+  fp16 * bf16;
+  bf16 / fp16;
+  fp16 / bf16;
   bf16 = fp16; // scalar-error {{assigning to '__bf16' from incompatible type '__fp16'}}
   fp16 = bf16; // scalar-error {{assigning to '__fp16' from incompatible type '__bf16'}}
-  bf16 + (b ? fp16 : bf16); // scalar-error {{incompatible operand types ('__fp16' and '__bf16')}}
+  bf16 + (b ? fp16 : bf16);
   *out = bf16;
 }
Index: clang/test/SemaCUDA/amdgpu-bf16.cu
===
--- clang/test/SemaCUDA/amdgpu-bf16.cu
+++ clang/test/SemaCUDA/amdgpu-bf16.cu
@@ -1,13 +1,8 @@
 // REQUIRES: amdgpu-registered-target
 // REQUIRES: x86-registered-target
 
-// RUN: %clang_cc1 "-triple" "x86_64-unknown-linux-gnu" "-aux-triple" "amdgcn-amd-amdhsa"\
-// RUN:"-target-cpu" "x86-64" -fsyntax-only -verify=amdgcn %s
-// RUN: %clang_cc1 "-aux-triple" 

[PATCH] D150913: [Clang][Bfloat16] Upgrade __bf16 to arithmetic type, change mangling, and extend excess precision support.

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs added inline comments.



Comment at: clang/lib/Basic/Targets/X86.cpp:362-363
   HasX87 = true;
+} else if (Feature == "+fullbf16") {
+  HasFullBFloat16 = true;
 }

pengfei wrote:
> Maybe not need it.
Clarified on the other thread but if you have questions please feel free to 
post here and I will address them.



Comment at: clang/lib/Basic/Targets/X86.cpp:381
 
 HasBFloat16 = SSELevel >= SSE2;
 

pengfei wrote:
> zahiraam wrote:
> > codemzs wrote:
> > > rjmccall wrote:
> > > > pengfei wrote:
> > > > > I'm not sure if I understand the meaning of `HasFullBFloat16`. If it 
> > > > > is used for target that supports arithmetic `__bf16`, we should not 
> > > > > use `+fullbf16` but always enable it for SSE2, i.e., `HasFullBFloat16 
> > > > > = SSELevel >= SSE2`. Because X86 GCC already supports arithmetic for 
> > > > > `__bf16`.
> > > > > 
> > > > > If this is used in the way like `HasLegalHalfType`, we should enable 
> > > > > it once we have a full BF16 ISA on X86. `fullbf16` doesn't make much 
> > > > > sense to me.
> > > > At the moment, we haven't done the work to emulate BFloat16 arithmetic 
> > > > in any of the three ways we can do that: Clang doesn't promote it in 
> > > > IRGen, LLVM doesn't promote it in legalization, and we don't have 
> > > > compiler-rt functions for it.  If we emit these instructions, they'll 
> > > > just sail through LLVM and fail in the backend.  So in the short term, 
> > > > we have to restrict this to targets that directly support BFloat16 
> > > > arithmetic in hardware, which doesn't include x86.
> > > > 
> > > > Once we have that emulation support, I agree that the x86 targets 
> > > > should enable this whenever they would enable `__bf16`.
> > > @rjmccall, I concur and just wanted to confirm this change indeed intends 
> > > to provide `BFloat16` emulation support, utilizing excess precision for 
> > > promotion to `float`. The `HasFullBFloat16` switch is designed to 
> > > determine excess precision support automatically when the hardware does 
> > > not natively support `bfloat16` arithmetic.
> > > At the moment, we haven't done the work to emulate BFloat16 arithmetic in 
> > > any of the three ways we can do that: Clang doesn't promote it in IRGen, 
> > > LLVM doesn't promote it in legalization, and we don't have compiler-rt 
> > > functions for it.  If we emit these instructions, they'll just sail 
> > > through LLVM and fail in the backend.  So in the short term, we have to 
> > > restrict this to targets that directly support BFloat16 arithmetic in 
> > > hardware, which doesn't include x86.
> > > 
> > > Once we have that emulation support, I agree that the x86 targets should 
> > > enable this whenever they would enable `__bf16`.
> > 
> > Would be nice to add a comment to clarify it. 
> > LLVM doesn't promote it in legalization, and we don't have compiler-rt 
> > functions for it.
> 
> That's not true: https://godbolt.org/z/jxf5E83vG.
> 
> > The `HasFullBFloat16` switch is designed to determine excess precision 
> > support automatically when the hardware does not natively support bfloat16 
> > arithmetic.
> 
> Makes sense to me.
@pengfei, you're right. As part of D126953, the x86 backend received `bfloat16` 
emulation support. Also, I hope my explanation about the `HasFullBFloat16` flag 
addressed your questions. Please let me know if further clarification/change is 
needed.



Comment at: clang/test/CodeGen/X86/bfloat16.cpp:2-3
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py 
UTC_ARGS: --version 2
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -target-feature +fullbf16 
-S -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -S -emit-llvm %s -o - | 
FileCheck -check-prefix=CHECK-NBF16 %s
+

zahiraam wrote:
> pengfei wrote:
> > The backend has already support lowering of `bfloat`, I don't think it's 
> > necessary to do extra work in FE unless for excess-precision.
> > The backend has already support lowering of `bfloat`, I don't think it's 
> > necessary to do extra work in FE unless for excess-precision.
> 
> +1.
@pengfei @zahiraam I added this test to verify bfloat16 IR gen functionality, 
considering both scenarios: with and without native bfloat16 support. However, 
if you believe it's more beneficial to omit it, I'm open to doing so. Happy to 
also move this test to another target that doesn't have backend support for 
emulation. 



Comment at: clang/test/CodeGen/X86/fexcess-precision-bfloat16.c:7
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown \
+// RUN: -fbfloat16-excess-precision=fast -target-feature +fullbf16 \
+// RUN: -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK-NO-EXT %s

pengfei wrote:
> The tests here make me guess you want to use `fullbf16` the same as 
> `HasLegalHalfType`.
Yes that is correct it is just to 

[PATCH] D150913: [Clang][BFloat16] Upgrade __bf16 to arithmetic type, change mangling, and extend excess precision support.

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs updated this revision to Diff 525298.
codemzs marked 5 inline comments as done.
codemzs retitled this revision from "[Clang][Bfloat16] Upgrade __bf16 to 
arithmetic type, change mangling, and extend excess precision support." to 
"[Clang][BFloat16] Upgrade __bf16 to arithmetic type, change mangling, and 
extend excess precision support.".
codemzs set the repository for this revision to rG LLVM Github Monorepo.
codemzs added a comment.

Incorporates suggestions provided by @rjmccall, @pengfei, and @zahiraam.

@rjmccall, your thorough restructuring of the floating-point types 
documentation is highly appreciated. Thank you.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150913/new/

https://reviews.llvm.org/D150913

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/FPOptions.def
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Driver/Options.td
  clang/lib/AST/Type.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CodeGen/X86/avx512bf16-error.c
  clang/test/CodeGen/X86/bfloat-mangle.cpp
  clang/test/CodeGen/X86/bfloat16.cpp
  clang/test/CodeGen/X86/fexcess-precision-bfloat16.c
  clang/test/CodeGenCUDA/amdgpu-bf16.cu
  clang/test/CodeGenCUDA/bf16.cu
  clang/test/Driver/fexcess-precision.c
  clang/test/Sema/arm-bf16-forbidden-ops.c
  clang/test/Sema/arm-bf16-forbidden-ops.cpp
  clang/test/Sema/arm-bfloat.cpp
  clang/test/SemaCUDA/amdgpu-bf16.cu
  clang/test/SemaCUDA/bf16.cu

Index: clang/test/SemaCUDA/bf16.cu
===
--- clang/test/SemaCUDA/bf16.cu
+++ clang/test/SemaCUDA/bf16.cu
@@ -2,32 +2,32 @@
 // REQUIRES: x86-registered-target
 
 // RUN: %clang_cc1 "-triple" "x86_64-unknown-linux-gnu" "-aux-triple" "nvptx64-nvidia-cuda" \
-// RUN:"-target-cpu" "x86-64" -fsyntax-only -verify=scalar %s
+// RUN:"-target-cpu" "x86-64" -fsyntax-only -verify=scalar -Wno-unused %s
 // RUN: %clang_cc1 "-aux-triple" "x86_64-unknown-linux-gnu" "-triple" "nvptx64-nvidia-cuda" \
-// RUN:-fcuda-is-device "-aux-target-cpu" "x86-64" -fsyntax-only -verify=scalar %s
+// RUN:-fcuda-is-device "-aux-target-cpu" "x86-64" -fsyntax-only -verify=scalar -Wno-unused %s
 
 #include "Inputs/cuda.h"
 
 __device__ void test(bool b, __bf16 *out, __bf16 in) {
   __bf16 bf16 = in; // No error on using the type itself.
 
-  bf16 + bf16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
-  bf16 - bf16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
-  bf16 * bf16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
-  bf16 / bf16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
+  bf16 + bf16;
+  bf16 - bf16;
+  bf16 * bf16;
+  bf16 / bf16;
 
   __fp16 fp16;
 
-  bf16 + fp16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
-  fp16 + bf16; // scalar-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
-  bf16 - fp16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
-  fp16 - bf16; // scalar-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
-  bf16 * fp16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
-  fp16 * bf16; // scalar-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
-  bf16 / fp16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
-  fp16 / bf16; // scalar-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
+  bf16 + fp16;
+  fp16 + bf16;
+  bf16 - fp16;
+  fp16 - bf16;
+  bf16 * fp16;
+  fp16 * bf16;
+  bf16 / fp16;
+  fp16 / bf16;
   bf16 = fp16; // scalar-error {{assigning to '__bf16' from incompatible type '__fp16'}}
   fp16 = bf16; // scalar-error {{assigning to '__fp16' from incompatible type '__bf16'}}
-  bf16 + (b ? fp16 : bf16); // scalar-error {{incompatible operand types ('__fp16' and '__bf16')}}
+  bf16 + (b ? fp16 : bf16);
   *out = bf16;
 }
Index: clang/test/SemaCUDA/amdgpu-bf16.cu
===
--- clang/test/SemaCUDA/amdgpu-bf16.cu
+++ clang/test/SemaCUDA/amdgpu-bf16.cu
@@ -1,13 +1,8 @@
 // REQUIRES: amdgpu-registered-target
 // REQUIRES: x86-registered-target
 
-// RUN: %clang_cc1 "-triple" "x86_64-unknown-linux-gnu" "-aux-triple" "amdgcn-amd-amdhsa"\
-// RUN:"-target-cpu" "x86-64" -fsyntax-only -verify=amdgcn %s
-// RUN: %clang_cc1 "-aux-tr

[PATCH] D150913: [Clang][BFloat16] Upgrade __bf16 to arithmetic type, change mangling, and extend excess precision support.

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:852
 ``double`` when passed to ``printf``, so the programmer must explicitly cast 
it to
 ``double`` before using it with an ``%f`` or similar specifier.
 

pengfei wrote:
> rjmccall wrote:
> > pengfei wrote:
> > > rjmccall wrote:
> > > > Suggested rework:
> > > > 
> > > > ```
> > > > Clang supports three half-precision (16-bit) floating point types: 
> > > > ``__fp16``,
> > > > ``_Float16`` and ``__bf16``.  These types are supported in all language
> > > > modes, but not on all targets:
> > > > 
> > > > - ``__fp16`` is supported on every target.
> > > > 
> > > > - ``_Float16`` is currently supported on the following targets:
> > > >   * 32-bit ARM (natively on some architecture versions)
> > > >   * 64-bit ARM (AArch64) (natively on ARMv8.2a and above)
> > > >   * AMDGPU (natively)
> > > >   * SPIR (natively)
> > > >   * X86 (if SSE2 is available; natively if AVX512-FP16 is also 
> > > > available)
> > > > 
> > > > - ``__bf16`` is currently supported on the following targets:
> > > >   * 32-bit ARM
> > > >   * 64-bit ARM (AArch64)
> > > >   * X86 (when SSE2 is available)
> > > > 
> > > > (For X86, SSE2 is available on 64-bit and all recent 32-bit processors.)
> > > > 
> > > > ``__fp16`` and ``_Float16`` both use the binary16 format from IEEE
> > > > 754-2008, which provides a 5-bit exponent and an 11-bit significand
> > > > (counting the implicit leading 1).  ``__bf16`` uses the `bfloat16
> > > > `_ format,
> > > > which provides an 8-bit exponent and an 8-bit significand; this is the 
> > > > same
> > > > exponent range as `float`, just with greatly reduced precision.
> > > > 
> > > > ``_Float16`` and ``__bf16`` follow the usual rules for arithmetic
> > > > floating-point types.  Most importantly, this means that arithmetic 
> > > > operations
> > > > on operands of these types are formally performed in the type and 
> > > > produce
> > > > values of the type.  ``__fp16`` does not follow those rules: most 
> > > > operations
> > > > immediately promote operands of type ``__fp16`` to ``float``, and so
> > > > arithmetic operations are defined to be performed in ``float`` and so 
> > > > result in
> > > > a value of type ``float`` (unless further promoted because of other 
> > > > operands).
> > > > See below for more information on the exact specifications of these 
> > > > types.
> > > > 
> > > > Only some of the supported processors for ``__fp16`` and ``__bf16`` 
> > > > offer
> > > > native hardware support for arithmetic in their corresponding formats.
> > > > The exact conditions are described in the lists above.  When compiling 
> > > > for a
> > > > processor without native support, Clang will perform the arithmetic in
> > > > ``float``, inserting extensions and truncations as necessary.  This can 
> > > > be
> > > > done in a way that exactly emulates the behavior of hardware support for
> > > > arithmetic, but it can require many extra operations.  By default, 
> > > > Clang takes
> > > > advantage of the C standard's allowances for excess precision in 
> > > > intermediate
> > > > operands in order to eliminate intermediate truncations within 
> > > > statements.
> > > > This is generally much faster but can generate different results from 
> > > > strict
> > > > operation-by-operation emulation.
> > > > 
> > > > The use of excess precision can be independently controlled for these 
> > > > two
> > > > types with the ``-ffloat16-excess-precision=`` and
> > > > ``-fbfloat16-excess-precision=`` options.  Valid values include:
> > > > - ``none`` (meaning to perform strict operation-by-operation emulation)
> > > > - ``standard`` (meaning that excess precision is permitted under the 
> > > > rules
> > > >   described in the standard, i.e. never across explicit casts or 
> > > > statements)
> > > > - ``fast`` (meaning that excess precision is permitted whenever the
> > > >   optimizer sees an opportunity to avoid truncations; currently this 
> > > > has no
> > > >   effect beyond ``standard``)
> > > > 
> > > > The ``_Float16`` type is an interchange floating type specified in
> > > >  ISO/IEC TS 18661-3:2015 ("Floating-point extensions for C").  It will
> > > > be supported on more targets as they define ABIs for it.
> > > > 
> > > > The ``__bf16`` type is a non-standard extension, but it generally 
> > > > follows
> > > > the rules for arithmetic interchange floating types from ISO/IEC TS
> > > > 18661-3:2015.  In previous versions of Clang, it was a storage-only type
> > > > that forbade arithmetic operations.  It will be supported on more 
> > > > targets
> > > > as they define ABIs for it.
> > > > 
> > > > The ``__fp16`` type was originally an ARM extension and is specified
> > > > by the `ARM C Language Extensions 
> > > > `_.
> > > > Clang uses the ``binary16`` format from IEEE 

[PATCH] D150913: [Clang][BFloat16] Upgrade __bf16 to arithmetic type, change mangling, and extend excess precision support.

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs updated this revision to Diff 525920.
codemzs marked 3 inline comments as done.
codemzs added a comment.

Addresses feedback on extended floating type documentation from @rjmccall and 
@pengfei


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150913/new/

https://reviews.llvm.org/D150913

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/FPOptions.def
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Driver/Options.td
  clang/lib/AST/Type.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CodeGen/X86/avx512bf16-error.c
  clang/test/CodeGen/X86/bfloat-mangle.cpp
  clang/test/CodeGen/X86/bfloat16.cpp
  clang/test/CodeGen/X86/fexcess-precision-bfloat16.c
  clang/test/CodeGenCUDA/amdgpu-bf16.cu
  clang/test/CodeGenCUDA/bf16.cu
  clang/test/Driver/fexcess-precision.c
  clang/test/Sema/arm-bf16-forbidden-ops.c
  clang/test/Sema/arm-bf16-forbidden-ops.cpp
  clang/test/Sema/arm-bfloat.cpp
  clang/test/SemaCUDA/amdgpu-bf16.cu
  clang/test/SemaCUDA/bf16.cu

Index: clang/test/SemaCUDA/bf16.cu
===
--- clang/test/SemaCUDA/bf16.cu
+++ clang/test/SemaCUDA/bf16.cu
@@ -2,32 +2,32 @@
 // REQUIRES: x86-registered-target
 
 // RUN: %clang_cc1 "-triple" "x86_64-unknown-linux-gnu" "-aux-triple" "nvptx64-nvidia-cuda" \
-// RUN:"-target-cpu" "x86-64" -fsyntax-only -verify=scalar %s
+// RUN:"-target-cpu" "x86-64" -fsyntax-only -verify=scalar -Wno-unused %s
 // RUN: %clang_cc1 "-aux-triple" "x86_64-unknown-linux-gnu" "-triple" "nvptx64-nvidia-cuda" \
-// RUN:-fcuda-is-device "-aux-target-cpu" "x86-64" -fsyntax-only -verify=scalar %s
+// RUN:-fcuda-is-device "-aux-target-cpu" "x86-64" -fsyntax-only -verify=scalar -Wno-unused %s
 
 #include "Inputs/cuda.h"
 
 __device__ void test(bool b, __bf16 *out, __bf16 in) {
   __bf16 bf16 = in; // No error on using the type itself.
 
-  bf16 + bf16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
-  bf16 - bf16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
-  bf16 * bf16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
-  bf16 / bf16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
+  bf16 + bf16;
+  bf16 - bf16;
+  bf16 * bf16;
+  bf16 / bf16;
 
   __fp16 fp16;
 
-  bf16 + fp16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
-  fp16 + bf16; // scalar-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
-  bf16 - fp16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
-  fp16 - bf16; // scalar-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
-  bf16 * fp16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
-  fp16 * bf16; // scalar-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
-  bf16 / fp16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
-  fp16 / bf16; // scalar-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
+  bf16 + fp16;
+  fp16 + bf16;
+  bf16 - fp16;
+  fp16 - bf16;
+  bf16 * fp16;
+  fp16 * bf16;
+  bf16 / fp16;
+  fp16 / bf16;
   bf16 = fp16; // scalar-error {{assigning to '__bf16' from incompatible type '__fp16'}}
   fp16 = bf16; // scalar-error {{assigning to '__fp16' from incompatible type '__bf16'}}
-  bf16 + (b ? fp16 : bf16); // scalar-error {{incompatible operand types ('__fp16' and '__bf16')}}
+  bf16 + (b ? fp16 : bf16);
   *out = bf16;
 }
Index: clang/test/SemaCUDA/amdgpu-bf16.cu
===
--- clang/test/SemaCUDA/amdgpu-bf16.cu
+++ clang/test/SemaCUDA/amdgpu-bf16.cu
@@ -1,13 +1,8 @@
 // REQUIRES: amdgpu-registered-target
 // REQUIRES: x86-registered-target
 
-// RUN: %clang_cc1 "-triple" "x86_64-unknown-linux-gnu" "-aux-triple" "amdgcn-amd-amdhsa"\
-// RUN:"-target-cpu" "x86-64" -fsyntax-only -verify=amdgcn %s
-// RUN: %clang_cc1 "-aux-triple" "x86_64-unknown-linux-gnu" "-triple" "amdgcn-amd-amdhsa"\
-// RUN:-fcuda-is-device "-aux-target-cpu" "x86-64" -fsyntax-only -verify=amdgcn %s
-
 // RUN: %clang_cc1 "-aux-triple" "x86_64-unknown-linux-gnu" "-triple" "r600-unknown-unknown"\
-// RUN:-fcuda-is-device "-aux-target-cpu" "x86-64" -fsyntax-only -verify=amdgcn,r600 %s
+// RUN:-fcuda-is-device "-aux-target-cpu" "x86-64" -fsyntax-only -verify=r600 %s
 
 // AMDGCN has storage-only support for bf16.

[PATCH] D150913: [Clang][BFloat16] Upgrade __bf16 to arithmetic type, change mangling, and extend excess precision support.

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs updated this revision to Diff 526072.
codemzs marked an inline comment as done.
codemzs set the repository for this revision to rG LLVM Github Monorepo.
codemzs added a comment.

Addresses @rjmccall suggestions.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150913/new/

https://reviews.llvm.org/D150913

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/FPOptions.def
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Driver/Options.td
  clang/lib/AST/Type.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CodeGen/X86/avx512bf16-error.c
  clang/test/CodeGen/X86/bfloat-mangle.cpp
  clang/test/CodeGen/X86/bfloat16.cpp
  clang/test/CodeGen/X86/fexcess-precision-bfloat16.c
  clang/test/CodeGenCUDA/amdgpu-bf16.cu
  clang/test/CodeGenCUDA/bf16.cu
  clang/test/Driver/fexcess-precision.c
  clang/test/Sema/arm-bf16-forbidden-ops.c
  clang/test/Sema/arm-bf16-forbidden-ops.cpp
  clang/test/Sema/arm-bfloat.cpp
  clang/test/SemaCUDA/amdgpu-bf16.cu
  clang/test/SemaCUDA/bf16.cu

Index: clang/test/SemaCUDA/bf16.cu
===
--- clang/test/SemaCUDA/bf16.cu
+++ clang/test/SemaCUDA/bf16.cu
@@ -2,32 +2,32 @@
 // REQUIRES: x86-registered-target
 
 // RUN: %clang_cc1 "-triple" "x86_64-unknown-linux-gnu" "-aux-triple" "nvptx64-nvidia-cuda" \
-// RUN:"-target-cpu" "x86-64" -fsyntax-only -verify=scalar %s
+// RUN:"-target-cpu" "x86-64" -fsyntax-only -verify=scalar -Wno-unused %s
 // RUN: %clang_cc1 "-aux-triple" "x86_64-unknown-linux-gnu" "-triple" "nvptx64-nvidia-cuda" \
-// RUN:-fcuda-is-device "-aux-target-cpu" "x86-64" -fsyntax-only -verify=scalar %s
+// RUN:-fcuda-is-device "-aux-target-cpu" "x86-64" -fsyntax-only -verify=scalar -Wno-unused %s
 
 #include "Inputs/cuda.h"
 
 __device__ void test(bool b, __bf16 *out, __bf16 in) {
   __bf16 bf16 = in; // No error on using the type itself.
 
-  bf16 + bf16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
-  bf16 - bf16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
-  bf16 * bf16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
-  bf16 / bf16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
+  bf16 + bf16;
+  bf16 - bf16;
+  bf16 * bf16;
+  bf16 / bf16;
 
   __fp16 fp16;
 
-  bf16 + fp16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
-  fp16 + bf16; // scalar-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
-  bf16 - fp16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
-  fp16 - bf16; // scalar-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
-  bf16 * fp16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
-  fp16 * bf16; // scalar-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
-  bf16 / fp16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
-  fp16 / bf16; // scalar-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
+  bf16 + fp16;
+  fp16 + bf16;
+  bf16 - fp16;
+  fp16 - bf16;
+  bf16 * fp16;
+  fp16 * bf16;
+  bf16 / fp16;
+  fp16 / bf16;
   bf16 = fp16; // scalar-error {{assigning to '__bf16' from incompatible type '__fp16'}}
   fp16 = bf16; // scalar-error {{assigning to '__fp16' from incompatible type '__bf16'}}
-  bf16 + (b ? fp16 : bf16); // scalar-error {{incompatible operand types ('__fp16' and '__bf16')}}
+  bf16 + (b ? fp16 : bf16);
   *out = bf16;
 }
Index: clang/test/SemaCUDA/amdgpu-bf16.cu
===
--- clang/test/SemaCUDA/amdgpu-bf16.cu
+++ clang/test/SemaCUDA/amdgpu-bf16.cu
@@ -1,13 +1,8 @@
 // REQUIRES: amdgpu-registered-target
 // REQUIRES: x86-registered-target
 
-// RUN: %clang_cc1 "-triple" "x86_64-unknown-linux-gnu" "-aux-triple" "amdgcn-amd-amdhsa"\
-// RUN:"-target-cpu" "x86-64" -fsyntax-only -verify=amdgcn %s
-// RUN: %clang_cc1 "-aux-triple" "x86_64-unknown-linux-gnu" "-triple" "amdgcn-amd-amdhsa"\
-// RUN:-fcuda-is-device "-aux-target-cpu" "x86-64" -fsyntax-only -verify=amdgcn %s
-
 // RUN: %clang_cc1 "-aux-triple" "x86_64-unknown-linux-gnu" "-triple" "r600-unknown-unknown"\
-// RUN:-fcuda-is-device "-aux-target-cpu" "x86-64" -fsyntax-only -verify=amdgcn,r600 %s
+// RUN:-fcuda-is-device "-aux-target-cpu" "x86-64" -fsyntax-only -verif

[PATCH] D150913: [Clang][BFloat16] Upgrade __bf16 to arithmetic type, change mangling, and extend excess precision support.

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs added a comment.

Hi @rjmccall, @pengfei, and @zahiraam,

Thank you for your valuable review and acceptance of my patch. As I lack commit 
access, could I kindly request one of you to perform the commit on my behalf? 
Please use the following command: `git commit --amend --author="M. Zeeshan 
Siddiqui "`.

git commit message:

  [Clang][BFloat16] Upgrade __bf16 to arithmetic type, change mangling,
  and extend excess precision support
  
  Pursuant to discussions at
  
https://discourse.llvm.org/t/rfc-c-23-p1467r9-extended-floating-point-types-and-standard-names/70033/22,
  this commit enhances the handling of the __bf16 type in Clang.
  - Firstly, it upgrades __bf16 from a storage-only type to an arithmetic
type.
  - Secondly, it changes the mangling of __bf16 to DF16b on all
architectures except ARM. This change has been made in
accordance with the finalization of the mangling for the
std::bfloat16_t type, as discussed at
https://github.com/itanium-cxx-abi/cxx-abi/pull/147.
  - Finally, this commit extends the existing excess precision support to
the __bf16 type. This applies to hardware architectures that do not
natively support bfloat16 arithmetic.
  Appropriate tests have been added to verify the effects of these
  changes and ensure no regressions in other areas of the compiler.
  
  Reviewed By: rjmccall, pengfei, zahiraam
  
  Differential Revision: https://reviews.llvm.org/D150913

I would like to add that I have rebased this patch on LLVM main as of just now 
and also applied clang formatting to this patch. However, to maintain 
consistency and respect untouched lines, I opted to reverse certain 
clang-format changes, which might result in a clang format failure on Debian. 
Should you deem it necessary for me to apply clang formatting across all lines 
regardless, I am open to revising the format accordingly.

Your assistance is greatly appreciated.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150913/new/

https://reviews.llvm.org/D150913

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151610: [Docs] Fix formatting issues in LanguageExtensions.rst

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs created this revision.
codemzs added a reviewer: pengfei.
Herald added a project: All.
codemzs requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Missing indentation.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D151610

Files:
  clang/docs/LanguageExtensions.rst


Index: clang/docs/LanguageExtensions.rst
===
--- clang/docs/LanguageExtensions.rst
+++ clang/docs/LanguageExtensions.rst
@@ -784,8 +784,8 @@
 to ``float``; see below for more information on this emulation.
 
 * ``__fp16`` is supported on all targets. The special semantics of this
-type mean that no arithmetic is ever performed directly on ``__fp16`` values;
-see below.
+  type mean that no arithmetic is ever performed directly on ``__fp16`` values;
+  see below.
 
 * ``_Float16`` is supported on the following targets:
   * 32-bit ARM (natively on some architecture versions)


Index: clang/docs/LanguageExtensions.rst
===
--- clang/docs/LanguageExtensions.rst
+++ clang/docs/LanguageExtensions.rst
@@ -784,8 +784,8 @@
 to ``float``; see below for more information on this emulation.
 
 * ``__fp16`` is supported on all targets. The special semantics of this
-type mean that no arithmetic is ever performed directly on ``__fp16`` values;
-see below.
+  type mean that no arithmetic is ever performed directly on ``__fp16`` values;
+  see below.
 
 * ``_Float16`` is supported on the following targets:
   * 32-bit ARM (natively on some architecture versions)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151610: [Docs] Fix Sphinx documentation formatting issues in LanguageExtensions.rst

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs updated this revision to Diff 526246.
codemzs retitled this revision from "[Docs] Fix formatting issues in 
LanguageExtensions.rst" to "[Docs] Fix Sphinx documentation formatting issues 
in LanguageExtensions.rst".
codemzs edited the summary of this revision.
codemzs added a reviewer: rjmccall.
codemzs added a subscriber: rjmccall.
codemzs added a comment.

Fix indentation and spacing.

Hi @pengfei and @rjmccall,

In the previous commit, the Sphinx documentation issues were overlooked due to 
an unexpected build error and the Sphinx build did not run as part of pre-build 
check. This was compounded by my unfamiliarity with the documentation 
generation process.

In this revision, I've addressed the indentation and spacing issues in the 
`.rst` files. The fixes have been validated locally using `ninja 
docs-clang-html` and `ninja docs-llvm-html`.

Apologies for the confusion in the previous submission. I look forward to your 
feedback on this revision.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151610/new/

https://reviews.llvm.org/D151610

Files:
  clang/docs/LanguageExtensions.rst


Index: clang/docs/LanguageExtensions.rst
===
--- clang/docs/LanguageExtensions.rst
+++ clang/docs/LanguageExtensions.rst
@@ -784,8 +784,8 @@
 to ``float``; see below for more information on this emulation.
 
 * ``__fp16`` is supported on all targets. The special semantics of this
-type mean that no arithmetic is ever performed directly on ``__fp16`` values;
-see below.
+  type mean that no arithmetic is ever performed directly on ``__fp16`` values;
+  see below.
 
 * ``_Float16`` is supported on the following targets:
   * 32-bit ARM (natively on some architecture versions)
@@ -809,7 +809,7 @@
 exponent range as `float`, just with greatly reduced precision.
 
 ``_Float16`` and ``__bf16`` follow the usual rules for arithmetic
-floating-point types.  Most importantly, this means that arithmetic operations
+floating-point types. Most importantly, this means that arithmetic operations
 on operands of these types are formally performed in the type and produce
 values of the type. ``__fp16`` does not follow those rules: most operations
 immediately promote operands of type ``__fp16`` to ``float``, and so
@@ -833,28 +833,29 @@
 
 The use of excess precision can be independently controlled for these two
 types with the ``-ffloat16-excess-precision=`` and
-``-fbfloat16-excess-precision=`` options.  Valid values include:
-- ``none`` (meaning to perform strict operation-by-operation emulation)
-- ``standard`` (meaning that excess precision is permitted under the rules
-  described in the standard, i.e. never across explicit casts or statements)
-- ``fast`` (meaning that excess precision is permitted whenever the
+``-fbfloat16-excess-precision=`` options. Valid values include:
+
+* ``none``: meaning to perform strict operation-by-operation emulation
+* ``standard``: meaning that excess precision is permitted under the rules
+  described in the standard, i.e. never across explicit casts or statements
+* ``fast``: meaning that excess precision is permitted whenever the
   optimizer sees an opportunity to avoid truncations; currently this has no
-  effect beyond ``standard``)
+  effect beyond ``standard``
 
-The ``_Float16`` type is an interchange floating type specified in
- ISO/IEC TS 18661-3:2015 ("Floating-point extensions for C").  It will
+The ``_Float16`` type is an interchange floating type specified in 
+ISO/IEC TS 18661-3:2015 ("Floating-point extensions for C"). It will
 be supported on more targets as they define ABIs for it.
 
 The ``__bf16`` type is a non-standard extension, but it generally follows
 the rules for arithmetic interchange floating types from ISO/IEC TS
-18661-3:2015.  In previous versions of Clang, it was a storage-only type
-that forbade arithmetic operations.  It will be supported on more targets
+18661-3:2015. In previous versions of Clang, it was a storage-only type
+that forbade arithmetic operations. It will be supported on more targets
 as they define ABIs for it.
 
 The ``__fp16`` type was originally an ARM extension and is specified
 by the `ARM C Language Extensions 
`_.
 Clang uses the ``binary16`` format from IEEE 754-2008 for ``__fp16``,
-not the ARM alternative format.  Operators that expect arithmetic operands
+not the ARM alternative format. Operators that expect arithmetic operands
 immediately promote ``__fp16`` operands to ``float``.
 
 It is recommended that portable code use ``_Float16`` instead of ``__fp16``,
@@ -870,7 +871,7 @@
 
 Because default argument promotion only applies to the standard floating-point
 types, ``_Float16`` values are not promoted to ``double`` when passed as 
variadic
-or untyped arguments.  As a consequence, some caution must be taken when using
+or untyped arguments. As a consequence, some caution must be taken when using
 certain libra

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs updated this revision to Diff 526519.
codemzs retitled this revision from "[Clang][C++23] Implement core language 
changes from P1467R9 extended floating-point types and standard names and adapt 
__bf16 to be arithmetic type" to "[Clang][C++23] Implement core language 
changes from P1467R9 extended floating-point types and standard names".
codemzs edited the summary of this revision.
codemzs set the repository for this revision to rG LLVM Github Monorepo.
codemzs added a comment.

Hi @tahonermann / @erichkeane ,

This change has been simplified and rebased onto D150913 
, which is now in LLVM main. I hope this 
makes the review process more straightforward.

CC: @rjmccall / @pengfei


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Lex/LiteralSupport.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/SMTConv.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/Type.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Lex/LiteralSupport.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CodeGenCXX/cxx23-fp-ext-std-names-p1467r9.cpp
  clang/test/CodeGenCXX/cxx23-vector-bfloat16.cpp
  clang/test/Sema/cxx23-fp-ext-std-names-p1467r9.cpp

Index: clang/test/Sema/cxx23-fp-ext-std-names-p1467r9.cpp
===
--- /dev/null
+++ clang/test/Sema/cxx23-fp-ext-std-names-p1467r9.cpp
@@ -0,0 +1,465 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++23 -target-feature +fullbf16 -verify -ast-dump %s | FileCheck %s
+
+_Float16 f16_val_1 = 1.0bf16; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type '__bf16'}}
+_Float16 f16_val_2 = 1.0f; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type 'float'}}
+_Float16 f16_val_3 = 1.0; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type 'double'}}
+_Float16 f16_val_4 = 1.0l; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type 'long double'}}
+_Float16 f16_val_6 = 1.0f16;
+//CHECK:  VarDecl {{.*}} f16_val_6 '_Float16' cinit
+//CHECK-NEXT: FloatingLiteral {{.*}} '_Float16' 1.00e+00
+_Float16 f16_val_7 = static_cast<_Float16>(1.0bf16); // expected-error {{static_cast from '__bf16' to '_Float16' is not allowed}}
+_Float16 f16_val_8 = static_cast<_Float16>(1.0f);
+//CHECK:  VarDecl {{.*}} f16_val_8 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'float' 1.00e+00
+_Float16 f16_val_9 = static_cast<_Float16>(1.0);
+//CHECK:  VarDecl {{.*}} f16_val_9 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'double' 1.00e+00
+_Float16 f16_val_10 = static_cast<_Float16>(1.0l);
+//CHECK:  VarDecl {{.*}} f16_val_10 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'long double' 1.00e+00
+_Float16 f16_val_11 = static_cast<_Float16>(1.0f16);
+//CHECK:  VarDecl {{.*}} f16_val_11 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} '_Float16' 1.00e+00
+
+decltype(0.0BF16) bf16_val_1 = 1.0f16; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type '_Float16'}}
+decltype(0.0BF16) bf16_val_2 = 1.0f; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type 'float'}}
+decltype(0.0BF16) bf16_val_3 = 1.0; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type 'double'}}
+decltype(0.0BF16) bf16_val_4 = 1.0l; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type 'long double'}}
+decltype(0.0BF16) bf16_val_5 = 1.0bf16;
+//CHECK:  VarDecl {{.*}} bf16_val_5 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: FloatingLiteral {{.*}} '__bf16' 1.00e+00
+
+decltype(0.0BF16) bf16_val_6 = static_cast(1.0f16); // expected-error {{static_cast from '_Float16' to 'decltype(0.BF16)' (aka '__bf16') is not allowed}}
+decltype(0.0BF16) bf16_val_7 = static_cast(1.0f);
+//CHECK:  VarDecl {{.*}} bf16_val_7 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} 'decltype(0.BF16)':'__bf16' static_cast 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'float' 1.00e+00
+decltype(0.0BF16) bf16_val_8 = sta

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs updated this revision to Diff 526524.
codemzs added a comment.

Remove unused header file.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Lex/LiteralSupport.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/SMTConv.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/Type.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Lex/LiteralSupport.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CodeGenCXX/cxx23-fp-ext-std-names-p1467r9.cpp
  clang/test/CodeGenCXX/cxx23-vector-bfloat16.cpp
  clang/test/Sema/cxx23-fp-ext-std-names-p1467r9.cpp

Index: clang/test/Sema/cxx23-fp-ext-std-names-p1467r9.cpp
===
--- /dev/null
+++ clang/test/Sema/cxx23-fp-ext-std-names-p1467r9.cpp
@@ -0,0 +1,465 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++23 -target-feature +fullbf16 -verify -ast-dump %s | FileCheck %s
+
+_Float16 f16_val_1 = 1.0bf16; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type '__bf16'}}
+_Float16 f16_val_2 = 1.0f; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type 'float'}}
+_Float16 f16_val_3 = 1.0; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type 'double'}}
+_Float16 f16_val_4 = 1.0l; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type 'long double'}}
+_Float16 f16_val_6 = 1.0f16;
+//CHECK:  VarDecl {{.*}} f16_val_6 '_Float16' cinit
+//CHECK-NEXT: FloatingLiteral {{.*}} '_Float16' 1.00e+00
+_Float16 f16_val_7 = static_cast<_Float16>(1.0bf16); // expected-error {{static_cast from '__bf16' to '_Float16' is not allowed}}
+_Float16 f16_val_8 = static_cast<_Float16>(1.0f);
+//CHECK:  VarDecl {{.*}} f16_val_8 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'float' 1.00e+00
+_Float16 f16_val_9 = static_cast<_Float16>(1.0);
+//CHECK:  VarDecl {{.*}} f16_val_9 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'double' 1.00e+00
+_Float16 f16_val_10 = static_cast<_Float16>(1.0l);
+//CHECK:  VarDecl {{.*}} f16_val_10 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'long double' 1.00e+00
+_Float16 f16_val_11 = static_cast<_Float16>(1.0f16);
+//CHECK:  VarDecl {{.*}} f16_val_11 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} '_Float16' 1.00e+00
+
+decltype(0.0BF16) bf16_val_1 = 1.0f16; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type '_Float16'}}
+decltype(0.0BF16) bf16_val_2 = 1.0f; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type 'float'}}
+decltype(0.0BF16) bf16_val_3 = 1.0; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type 'double'}}
+decltype(0.0BF16) bf16_val_4 = 1.0l; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type 'long double'}}
+decltype(0.0BF16) bf16_val_5 = 1.0bf16;
+//CHECK:  VarDecl {{.*}} bf16_val_5 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: FloatingLiteral {{.*}} '__bf16' 1.00e+00
+
+decltype(0.0BF16) bf16_val_6 = static_cast(1.0f16); // expected-error {{static_cast from '_Float16' to 'decltype(0.BF16)' (aka '__bf16') is not allowed}}
+decltype(0.0BF16) bf16_val_7 = static_cast(1.0f);
+//CHECK:  VarDecl {{.*}} bf16_val_7 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} 'decltype(0.BF16)':'__bf16' static_cast 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'float' 1.00e+00
+decltype(0.0BF16) bf16_val_8 = static_cast(1.0);
+//CHECK:  VarDecl {{.*}} bf16_val_8 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} 'decltype(0.BF16)':'__bf16' static_cast 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'double' 1.00e+00
+decltype(0.0BF16) bf16_val_9 = static_cast(1.0l);
+//CHECK:  VarDecl {{.*}} bf16_val_9 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} 'decltype(0.BF16)':'__bf16' static_cast 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'long double' 1.00e+00
+decltype(0.0BF16) bf16_val_10 = static_cast(1.0bf16);
+//CHECK:  VarDecl {{.*}} bf16_val_10 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} 

[PATCH] D150291: [Clang] Rename internal type identifier(s) for __bf16 to BF16Ty

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs abandoned this revision.
codemzs added a comment.

Closing this as it has been resolved by D150913 
.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150291/new/

https://reviews.llvm.org/D150291

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs added a comment.

In D149573#4390863 , @stuij wrote:

> This is going to be a very unhelpful comment. After looking through the 
> changes, I don't have any comments to make, but I also don't feel comfortable 
> to accept this revision as I don't feel to know enough about the front-end.

@stuij, I sincerely appreciate you taking the time to review the changes. Your 
hesitation due to unfamiliarity with the front-end elements is completely 
understandable, and I respect your candid feedback.

@erichkeane, given your extensive contributions to the core `Sema`* files, I 
believe your expertise and experience would be particularly valuable in 
reviewing the changes I've made. I recall your initial informal approval for 
the change, and since then, I've further refined it after incorporating the 
outcomes of D150913 . I'd be most 
appreciative if you could please review this revision once again.

My intention is to ensure this revision aligns with our shared vision for 
LLVM/Clang, and your reviews will greatly contribute to this goal. If there are 
any other changes or improvements required for the successful landing of this 
revision, please feel free to let me know.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs added a subscriber: aaron.ballman.
codemzs added a comment.

In D149573#4391013 , @erichkeane 
wrote:

> In D149573#4390895 , @codemzs wrote:
>
>> In D149573#4390863 , @stuij wrote:
>>
>>> This is going to be a very unhelpful comment. After looking through the 
>>> changes, I don't have any comments to make, but I also don't feel 
>>> comfortable to accept this revision as I don't feel to know enough about 
>>> the front-end.
>>
>> @stuij, I sincerely appreciate you taking the time to review the changes. 
>> Your hesitation due to unfamiliarity with the front-end elements is 
>> completely understandable, and I respect your candid feedback.
>>
>> @erichkeane, given your extensive contributions to the core `Sema`* files, I 
>> believe your expertise and experience would be particularly valuable in 
>> reviewing the changes I've made. I recall your initial informal approval for 
>> the change, and since then, I've further refined it after incorporating the 
>> outcomes of D150913 . I'd be most 
>> appreciative if you could please review this revision once again.
>>
>> My intention is to ensure this revision aligns with our shared vision for 
>> LLVM/Clang, and your reviews will greatly contribute to this goal. If there 
>> are any other changes or improvements required for the successful landing of 
>> this revision, please feel free to let me know.
>
> I'll put you on my list to re-review for early next week, though Aaron 
> probably needs to do a look through this as well.

Thank you, @erichkeane that would be great, are you referring to @aaron.ballman 
?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names and introduce Bfloat16 arithmetic type.

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs marked 2 inline comments as done.
codemzs added inline comments.



Comment at: clang/include/clang/Basic/LangOptions.def:468
 
+LANGOPT(ExperimentalNewItaniumMangling, 1, 0, "experimental new Itanium 
mangling")
+

erichkeane wrote:
> codemzs wrote:
> > erichkeane wrote:
> > > I'm not sure I like the implications or maintainability of this.  This is 
> > > something that is likely to get out of hand too quickly.  We probably 
> > > need to just figure out what the itanium mangling is GOING to be (perhaps 
> > > @rjmccall has some  insight?), and just implement that.
> > > 
> > > Also, this isn't really a 'Language Option', so much as a codegen option.
> > Thank you for your valuable feedback. Based on your suggestion and 
> > considering that GCC has already implemented the mangling as `DF16b`, I 
> > agree that if we have reasonable confidence in the direction the mangling 
> > will take, it would be better to implement it directly instead of guarding 
> > it with an experimental flag. Therefore, I will be removing the flag. I 
> > initially added the flag since @tahonermann was on board with implementing 
> > the bf16 arithmetic type, assuming the mangling was finalized.
> > 
> > However, I understand your concerns and would appreciate further input from 
> > both @tahonermann and @rjmccall on this matter. My intention is to avoid 
> > stalling the progress of this change due to mangling finalization.
> > 
> > I'm open to further discussion and collaboration to ensure we make the 
> > right decision for our project while maintaining the momentum of the review 
> > process.
> Thanks, I think this is a good direction for this patch to take.
@erichkeane @tahonermann Itanium mangling is now finalized as `DF16b`and [[ 
https://github.com/itanium-cxx-abi/cxx-abi/pull/147#issuecomment-1540692344 | 
merged  ]]into the github repository. 


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names and introduce Bfloat16 arithmetic type.

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs marked an inline comment as done.
codemzs added a comment.

Hi @rjmccall and @erichkeane,

I would like to inquire about the necessity of implementing excess precision 
support for `std::bfloat16_t` in this patch. In reference to the discussion on 
https://reviews.llvm.org/D136919, it was mentioned that introducing 
`std::bfloat16_t` in Clang requires proper mangling, semantics, and excess 
precision support.

However, this change includes a front-end flag that enables `bfloat16` 
arithmetic only when the target natively supports `bfloat16` operations. Given 
this restriction, is it still essential to provide excess precision support for 
`std::bfloat16_t` in this patch?

Thank you for your guidance.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names and introduce Bfloat16 arithmetic type.

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs added a comment.

Hi @rjmccall and @erichkeane,

I would like to inquire about the necessity of implementing excess precision 
support for `std::bfloat16_t` in this patch. In reference to the discussion on 
https://reviews.llvm.org/D136919, it was mentioned that introducing 
`std::bfloat16_t` in Clang requires proper mangling, semantics, and excess 
precision support.

However, this change includes a front-end flag that enables `bfloat16` 
arithmetic only when the target natively supports `bfloat16` operations. Given 
this restriction, is it still essential to provide excess precision support for 
`std::bfloat16_t` in this patch?

Thank you for your guidance.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names and introduce Bfloat16 arithmetic type.

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs marked an inline comment as done.
codemzs added a comment.

In D149573#4332549 , @tahonermann 
wrote:

> I reviewed about a third of this, but then stopped due to the `__bf16` vs 
> `std::bfloat16_t` naming issues. I think the existing names that use 
> "bfloat16" to support the `__bf16` type should be renamed, in a separate 
> patch, and this patch rebased on top of it. We are sure to make mistakes if 
> this confusing situation is not resolved.

@tahonermann, thank you for your review and highlighting the naming issues with 
`__bf16` and `std::bfloat16_t`. I agree that reversing the type names will 
improve readability and maintainability. I considered this while working on the 
code and appreciate your suggestion to address it in a separate patch before 
rebasing this one.




Comment at: clang/include/clang/Lex/LiteralSupport.h:75
   bool isBitInt : 1;// 1wb, 1uwb (C2x)
+  bool isBF16 : 1;  // 1.0bf
   uint8_t MicrosoftInteger; // Microsoft suffix extension i8, i16, i32, or i64.

tahonermann wrote:
> Is this for `__bf16` or for `std::bfloat16_t`?
Its for `std::bfloat16_t`, I don't believe `__bf16` has a literal suffix. 


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D150291: [Clang] Rename internal type identifier(s) for `__bf16` to `BF16Ty`

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs created this revision.
codemzs added reviewers: tahonermann, erichkeane, stuij.
Herald added subscribers: mattd, gchakrabarti, asavonic, ctetreau, kerbowa, 
arphaman, kristof.beyls, jvesely.
Herald added a project: All.
codemzs requested review of this revision.
Herald added subscribers: lldb-commits, cfe-commits, jholewinski.
Herald added projects: clang, LLDB.

  This change updates internal type identifiers for `__bf16` from
  `BFloat16Ty` to `BF16Ty` and renames any associated variables and
  function names accordingly. The rationale for this change comes from
  the review feedback on https://reviews.llvm.org/D149573, which pointed
  out the confusing naming issues between `__bf16` and the upcoming
  `std::bfloat16_t`. This modification only affects LLVM/Clang specific
  code and does not interfere with target-specific code, such as
  NeonEmitters, SVE Type, AArch64, etc. The existing names are being
  updated to avoid potential mistakes and enhance clarity in the codebase.
  The change is made in a separate patch, as suggested in the review, to
  ensure a smooth integration of std::bfloat16_t support.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D150291

Files:
  clang/include/clang-c/Index.h
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/BuiltinTypes.def
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Specifiers.h
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Basic/arm_neon_incl.td
  clang/include/clang/Sema/DeclSpec.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/MicrosoftMangle.cpp
  clang/lib/AST/NSAPI.cpp
  clang/lib/AST/PrintfFormatString.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypeLoc.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Basic/Targets/ARM.h
  clang/lib/Basic/Targets/NVPTX.cpp
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CodeGenTypes.cpp
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/Index/USRGeneration.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Sema/DeclSpec.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaTemplateVariadic.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Serialization/ASTCommon.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/tools/libclang/CXType.cpp
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp

Index: lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
===
--- lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -4909,7 +4909,7 @@
 case clang::BuiltinType::Float128:
 case clang::BuiltinType::Double:
 case clang::BuiltinType::LongDouble:
-case clang::BuiltinType::BFloat16:
+case clang::BuiltinType::BF16:
 case clang::BuiltinType::Ibm128:
   return lldb::eEncodingIEEE754;
 
Index: clang/tools/libclang/CXType.cpp
===
--- clang/tools/libclang/CXType.cpp
+++ clang/tools/libclang/CXType.cpp
@@ -618,7 +618,7 @@
 TKIND(Pipe);
 TKIND(Attributed);
 TKIND(BTFTagAttributed);
-TKIND(BFloat16);
+TKIND(BF16);
 #define IMAGE_TYPE(ImgType, Id, SingletonId, Access, Suffix) TKIND(Id);
 #include "clang/Basic/OpenCLImageTypes.def"
 #undef IMAGE_TYPE
Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -7026,8 +7026,8 @@
 case PREDEF_TYPE_INT128_ID:
   T = Context.Int128Ty;
   break;
-case PREDEF_TYPE_BFLOAT16_ID:
-  T = Context.BFloat16Ty;
+case PREDEF_TYPE_BF16_ID:
+  T = Context.BF16Ty;
   break;
 case PREDEF_TYPE_HALF_ID:
   T = Context.HalfTy;
Index: clang/lib/Serialization/ASTCommon.cpp
===
--- clang/lib/Serialization/ASTCommon.cpp
+++ clang/lib/Serialization/ASTCommon.cpp
@@ -270,8 +270,8 @@
   case BuiltinType::OMPIterator:
 ID = PREDEF_TYPE_OMP_ITERATOR;
 break;
-  case BuiltinType::BFloat16:
-ID = PREDEF_TYPE_BFLOAT16_ID;
+  case BuiltinType::BF16:
+ID = PREDEF_TYPE_BF16_ID;
 break;
   }
 
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaTy

[PATCH] D150291: [Clang] Rename internal type identifier(s) for __bf16 to BF16Ty

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs updated this revision to Diff 521163.
codemzs marked 4 inline comments as done.
codemzs retitled this revision from "[Clang] Rename internal type identifier(s) 
for `__bf16` to `BF16Ty`" to "[Clang] Rename internal type identifier(s) for 
__bf16 to BF16Ty".
codemzs added a comment.

PR feedback: Revert style changes.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150291/new/

https://reviews.llvm.org/D150291

Files:
  clang/include/clang-c/Index.h
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/BuiltinTypes.def
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Specifiers.h
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Basic/arm_neon_incl.td
  clang/include/clang/Sema/DeclSpec.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/MicrosoftMangle.cpp
  clang/lib/AST/NSAPI.cpp
  clang/lib/AST/PrintfFormatString.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypeLoc.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Basic/Targets/ARM.h
  clang/lib/Basic/Targets/NVPTX.cpp
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CodeGenTypes.cpp
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/Index/USRGeneration.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Sema/DeclSpec.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaTemplateVariadic.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Serialization/ASTCommon.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/tools/libclang/CXType.cpp
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp

Index: lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
===
--- lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -4909,7 +4909,7 @@
 case clang::BuiltinType::Float128:
 case clang::BuiltinType::Double:
 case clang::BuiltinType::LongDouble:
-case clang::BuiltinType::BFloat16:
+case clang::BuiltinType::BF16:
 case clang::BuiltinType::Ibm128:
   return lldb::eEncodingIEEE754;
 
Index: clang/tools/libclang/CXType.cpp
===
--- clang/tools/libclang/CXType.cpp
+++ clang/tools/libclang/CXType.cpp
@@ -618,7 +618,7 @@
 TKIND(Pipe);
 TKIND(Attributed);
 TKIND(BTFTagAttributed);
-TKIND(BFloat16);
+TKIND(BF16);
 #define IMAGE_TYPE(ImgType, Id, SingletonId, Access, Suffix) TKIND(Id);
 #include "clang/Basic/OpenCLImageTypes.def"
 #undef IMAGE_TYPE
Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -7024,8 +7024,8 @@
 case PREDEF_TYPE_INT128_ID:
   T = Context.Int128Ty;
   break;
-case PREDEF_TYPE_BFLOAT16_ID:
-  T = Context.BFloat16Ty;
+case PREDEF_TYPE_BF16_ID:
+  T = Context.BF16Ty;
   break;
 case PREDEF_TYPE_HALF_ID:
   T = Context.HalfTy;
Index: clang/lib/Serialization/ASTCommon.cpp
===
--- clang/lib/Serialization/ASTCommon.cpp
+++ clang/lib/Serialization/ASTCommon.cpp
@@ -270,8 +270,8 @@
   case BuiltinType::OMPIterator:
 ID = PREDEF_TYPE_OMP_ITERATOR;
 break;
-  case BuiltinType::BFloat16:
-ID = PREDEF_TYPE_BFLOAT16_ID;
+  case BuiltinType::BF16:
+ID = PREDEF_TYPE_BF16_ID;
 break;
   }
 
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -1518,12 +1518,12 @@
 Result = Context.Float16Ty;
 break;
   case DeclSpec::TST_half:Result = Context.HalfTy; break;
-  case DeclSpec::TST_BFloat16:
-if (!S.Context.getTargetInfo().hasBFloat16Type() &&
+  case DeclSpec::TST_BF16:
+if (!S.Context.getTargetInfo().hasBF16Type() &&
 !(S.getLangOpts().OpenMP && S.getLangOpts().OpenMPIsDevice) &&
 !S.getLangOpts().SYCLIsDevice)
   S.Diag(DS.getTypeSpecTypeLoc(), diag::err_type_unsupported) << "__bf16";
-Result = Context.BFloat16Ty;
+Result = Context.BF16Ty;
 break;
   case DeclSpec::TST_float:   Result = Context.FloatTy; break;
   case DeclSpec::TST_double:
@@ -8133,7 +8133,7 @@
  BTy->getKind() == BuiltinType::ULongLong |

[PATCH] D150291: [Clang] Rename internal type identifier(s) for __bf16 to BF16Ty

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs added a comment.

Thank you for pointing that out and for reviewing my code. I appreciate your 
guidance. I was following the LLVM contribution guidelines to use git 
clang-format, but I understand the importance of maintaining existing code 
styles that may be altered by git-clang format. I will be more mindful of this 
in the future. I have reverted the style changes and updated the patch as per 
your feedback.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150291/new/

https://reviews.llvm.org/D150291

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D150291: [Clang] Rename internal type identifier(s) for __bf16 to BF16Ty

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs updated this revision to Diff 521353.
codemzs marked 2 inline comments as done.
codemzs set the repository for this revision to rG LLVM Github Monorepo.
codemzs added a comment.

Update comments as per feedback from @tahonermann


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150291/new/

https://reviews.llvm.org/D150291

Files:
  clang/include/clang-c/Index.h
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/BuiltinTypes.def
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Specifiers.h
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Basic/arm_neon_incl.td
  clang/include/clang/Sema/DeclSpec.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/MicrosoftMangle.cpp
  clang/lib/AST/NSAPI.cpp
  clang/lib/AST/PrintfFormatString.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypeLoc.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Basic/Targets/ARM.h
  clang/lib/Basic/Targets/NVPTX.cpp
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CodeGenTypes.cpp
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/Index/USRGeneration.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Sema/DeclSpec.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaTemplateVariadic.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Serialization/ASTCommon.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/tools/libclang/CXType.cpp
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp

Index: lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
===
--- lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -4909,7 +4909,7 @@
 case clang::BuiltinType::Float128:
 case clang::BuiltinType::Double:
 case clang::BuiltinType::LongDouble:
-case clang::BuiltinType::BFloat16:
+case clang::BuiltinType::BF16:
 case clang::BuiltinType::Ibm128:
   return lldb::eEncodingIEEE754;
 
Index: clang/tools/libclang/CXType.cpp
===
--- clang/tools/libclang/CXType.cpp
+++ clang/tools/libclang/CXType.cpp
@@ -618,7 +618,7 @@
 TKIND(Pipe);
 TKIND(Attributed);
 TKIND(BTFTagAttributed);
-TKIND(BFloat16);
+TKIND(BF16);
 #define IMAGE_TYPE(ImgType, Id, SingletonId, Access, Suffix) TKIND(Id);
 #include "clang/Basic/OpenCLImageTypes.def"
 #undef IMAGE_TYPE
Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -7024,8 +7024,8 @@
 case PREDEF_TYPE_INT128_ID:
   T = Context.Int128Ty;
   break;
-case PREDEF_TYPE_BFLOAT16_ID:
-  T = Context.BFloat16Ty;
+case PREDEF_TYPE_BF16_ID:
+  T = Context.BF16Ty;
   break;
 case PREDEF_TYPE_HALF_ID:
   T = Context.HalfTy;
Index: clang/lib/Serialization/ASTCommon.cpp
===
--- clang/lib/Serialization/ASTCommon.cpp
+++ clang/lib/Serialization/ASTCommon.cpp
@@ -270,8 +270,8 @@
   case BuiltinType::OMPIterator:
 ID = PREDEF_TYPE_OMP_ITERATOR;
 break;
-  case BuiltinType::BFloat16:
-ID = PREDEF_TYPE_BFLOAT16_ID;
+  case BuiltinType::BF16:
+ID = PREDEF_TYPE_BF16_ID;
 break;
   }
 
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -1518,12 +1518,12 @@
 Result = Context.Float16Ty;
 break;
   case DeclSpec::TST_half:Result = Context.HalfTy; break;
-  case DeclSpec::TST_BFloat16:
-if (!S.Context.getTargetInfo().hasBFloat16Type() &&
+  case DeclSpec::TST_BF16:
+if (!S.Context.getTargetInfo().hasBF16Type() &&
 !(S.getLangOpts().OpenMP && S.getLangOpts().OpenMPIsDevice) &&
 !S.getLangOpts().SYCLIsDevice)
   S.Diag(DS.getTypeSpecTypeLoc(), diag::err_type_unsupported) << "__bf16";
-Result = Context.BFloat16Ty;
+Result = Context.BF16Ty;
 break;
   case DeclSpec::TST_float:   Result = Context.FloatTy; break;
   case DeclSpec::TST_double:
@@ -8133,7 +8133,7 @@
  BTy->getKind() == BuiltinType::ULongLong ||
  BTy->getKind() == BuiltinType::Float ||

[PATCH] D150291: [Clang] Rename internal type identifier(s) for __bf16 to BF16Ty

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs marked an inline comment as done.
codemzs added a comment.

In D150291#4335360 , @barannikov88 
wrote:

> The summary as it is will be hard to read in git log. Please split it into 
> multiple lines 72~80 chars each.
> https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

I've provided the git log message that I see on my end below. I ensured that it 
is split into multiple lines, with each line not exceeding the character limit. 
Please let me know if this isn't inline with the LLVM contribution standards.

F27408097: image.png 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150291/new/

https://reviews.llvm.org/D150291

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D150291: [Clang] Rename internal type identifier(s) for __bf16 to BF16Ty

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs updated this revision to Diff 521363.
codemzs marked an inline comment as done.
codemzs added a comment.

Addressing feedback from @barannikov88


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150291/new/

https://reviews.llvm.org/D150291

Files:
  clang/include/clang-c/Index.h
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/BuiltinTypes.def
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Specifiers.h
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Basic/arm_neon_incl.td
  clang/include/clang/Sema/DeclSpec.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/MicrosoftMangle.cpp
  clang/lib/AST/NSAPI.cpp
  clang/lib/AST/PrintfFormatString.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypeLoc.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Basic/Targets/ARM.h
  clang/lib/Basic/Targets/NVPTX.cpp
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/ABIInfo.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CodeGenTypes.cpp
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/Index/USRGeneration.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Sema/DeclSpec.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaTemplateVariadic.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Serialization/ASTCommon.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/tools/libclang/CXType.cpp
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp

Index: lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
===
--- lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -4909,7 +4909,7 @@
 case clang::BuiltinType::Float128:
 case clang::BuiltinType::Double:
 case clang::BuiltinType::LongDouble:
-case clang::BuiltinType::BFloat16:
+case clang::BuiltinType::BF16:
 case clang::BuiltinType::Ibm128:
   return lldb::eEncodingIEEE754;
 
Index: clang/tools/libclang/CXType.cpp
===
--- clang/tools/libclang/CXType.cpp
+++ clang/tools/libclang/CXType.cpp
@@ -618,7 +618,7 @@
 TKIND(Pipe);
 TKIND(Attributed);
 TKIND(BTFTagAttributed);
-TKIND(BFloat16);
+TKIND(BF16);
 #define IMAGE_TYPE(ImgType, Id, SingletonId, Access, Suffix) TKIND(Id);
 #include "clang/Basic/OpenCLImageTypes.def"
 #undef IMAGE_TYPE
Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -7024,8 +7024,8 @@
 case PREDEF_TYPE_INT128_ID:
   T = Context.Int128Ty;
   break;
-case PREDEF_TYPE_BFLOAT16_ID:
-  T = Context.BFloat16Ty;
+case PREDEF_TYPE_BF16_ID:
+  T = Context.BF16Ty;
   break;
 case PREDEF_TYPE_HALF_ID:
   T = Context.HalfTy;
Index: clang/lib/Serialization/ASTCommon.cpp
===
--- clang/lib/Serialization/ASTCommon.cpp
+++ clang/lib/Serialization/ASTCommon.cpp
@@ -270,8 +270,8 @@
   case BuiltinType::OMPIterator:
 ID = PREDEF_TYPE_OMP_ITERATOR;
 break;
-  case BuiltinType::BFloat16:
-ID = PREDEF_TYPE_BFLOAT16_ID;
+  case BuiltinType::BF16:
+ID = PREDEF_TYPE_BF16_ID;
 break;
   }
 
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -1518,12 +1518,12 @@
 Result = Context.Float16Ty;
 break;
   case DeclSpec::TST_half:Result = Context.HalfTy; break;
-  case DeclSpec::TST_BFloat16:
-if (!S.Context.getTargetInfo().hasBFloat16Type() &&
+  case DeclSpec::TST_BF16:
+if (!S.Context.getTargetInfo().hasBF16Type() &&
 !(S.getLangOpts().OpenMP && S.getLangOpts().OpenMPIsDevice) &&
 !S.getLangOpts().SYCLIsDevice)
   S.Diag(DS.getTypeSpecTypeLoc(), diag::err_type_unsupported) << "__bf16";
-Result = Context.BFloat16Ty;
+Result = Context.BF16Ty;
 break;
   case DeclSpec::TST_float:   Result = Context.FloatTy; break;
   case DeclSpec::TST_double:
@@ -8133,7 +8133,7 @@
  BTy->getKind() == BuiltinType::ULongLong ||
  BTy->getKind() == BuiltinType::Float ||
  BTy->getKind() == BuiltinType::Half ||
- BTy->getKind() == BuiltinType::BF

[PATCH] D150291: [Clang] Rename internal type identifier(s) for __bf16 to BF16Ty

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs added a comment.

In D150291#4335352 , @tahonermann 
wrote:

> Thanks for all the updates @codemzs! I'm going to go ahead and accept. But 
> please wait a few days for recently subscribed folks to have a chance to 
> comment before landing this.

Thank you, @tahonermann, for the review. I will hold off on landing this until 
next week to allow sufficient time for others who are subscribed to review as 
well.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150291/new/

https://reviews.llvm.org/D150291

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names and introduce Bfloat16 arithmetic type.

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs marked an inline comment as done.
codemzs added a comment.

In D149573#4337480 , @stuij wrote:

> I made a comment on the RFC 
> 
>  to understand if we really need/want a new bfloat16 type.

Thank you, @stuij, for your input. I will continue to follow the consensus on 
the RFC regarding the introduction of a new bfloat16 type. For context, my 
initial implementation transitioned the existing storage-only `__bf16` type 
into an arithmetic type. If the decision leans towards not introducing a new 
`bfloat16` type, I'm prepared to revert my changes to utilize the `__bf16` 
type. To ensure our collective efforts are effectively streamlined and avoid 
any potential duplication, I am committed to aligning my work with the 
community consensus and ongoing discussions.

@tahonermann, when you have a moment, your guidance would be greatly 
appreciated.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D150291: [Clang] Rename internal type identifier(s) for __bf16 to BF16Ty

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs added a comment.

In D150291#4338118 , @tahonermann 
wrote:

>> I do wonder if we need two bfloat implementations, but for that I'll leave a 
>> comment on D149573 .
>
> Given the discussions occurring in D149573 
> , let's hold off on landing this for now. 
> It is sounding like we might have direction for repurposing `__bf16` for 
> `std::bfloat16_t` (and a future `_BFloat16` C type; with `__bf16` retained as 
> an alternate spelling). If we go in that direction, then we would presumably 
> want a change that goes in the opposite direction of this patch; a change 
> that migrates "bf16" names towards "bfloat16". Let's focus on confirming that 
> direction first. I'll mark this as requesting changes for now while we figure 
> this out.

Thank you for your guidance, @tahonermann. I agree it's prudent to establish a 
confirmed direction for reusing `__bf16` to implement `std::bfloat16_t` as an 
arithmetic type before proceeding. If we decide to take this route, I 
understand that we'll be looking towards a change that aligns "bf16" names more 
closely with "bfloat16".

In the meantime, I will revert to my initial change in D149573 
 which repurposed `__bf16` type, and present 
it for further discussion. This, along with a summary of the RFC discussion, 
should help us reach a consensus. I welcome any further insights or 
considerations you might think pertinent to this process.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150291/new/

https://reviews.llvm.org/D150291

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D150913: [Clang][Bfloat16] Upgrade __bf16 to arithmetic type, change mangling, and extend excess precision support.

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs created this revision.
codemzs added reviewers: tahonermann, rjmccall, zahiraam, stuij, pengfei, 
erichkeane.
Herald added subscribers: mattd, gchakrabarti, asavonic, kerbowa, 
kristof.beyls, jvesely.
Herald added a project: All.
codemzs requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, jholewinski.
Herald added a project: clang.

Pursuant to RFC 

 discussions, this change enhances the handling of the `__bf16` type in Clang.

- Firstly, it upgrades `__bf16` from a storage-only type to an arithmetic type.
- Secondly, it changes the mangling of `__bf16` to `DF16b` on all architectures 
except ARM. This change has been made in accordance with the finalization of 
the mangling for the `std::bfloat16_t` type, as discussed at 
https://github.com/itanium-cxx-abi/cxx-abi/pull/147.
- Finally, this commit extends the existing excess precision support to the 
`__bf16` type. This applies to hardware architectures that do not natively 
support `bfloat16` arithmetic.

Appropriate tests have been added to verify the effects of these changes and 
ensure no regressions in other areas of the compiler.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D150913

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/FPOptions.def
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Driver/Options.td
  clang/lib/AST/Type.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CodeGen/X86/avx512bf16-error.c
  clang/test/CodeGen/X86/bfloat-mangle.cpp
  clang/test/CodeGen/X86/bfloat16.cpp
  clang/test/CodeGen/X86/fexcess-precision-bfloat16.c
  clang/test/CodeGenCUDA/amdgpu-bf16.cu
  clang/test/CodeGenCUDA/bf16.cu
  clang/test/Driver/fexcess-precision.c
  clang/test/Sema/arm-bf16-forbidden-ops.c
  clang/test/Sema/arm-bf16-forbidden-ops.cpp
  clang/test/Sema/arm-bfloat.cpp
  clang/test/SemaCUDA/amdgpu-bf16.cu
  clang/test/SemaCUDA/bf16.cu

Index: clang/test/SemaCUDA/bf16.cu
===
--- clang/test/SemaCUDA/bf16.cu
+++ clang/test/SemaCUDA/bf16.cu
@@ -2,32 +2,32 @@
 // REQUIRES: x86-registered-target
 
 // RUN: %clang_cc1 "-triple" "x86_64-unknown-linux-gnu" "-aux-triple" "nvptx64-nvidia-cuda" \
-// RUN:"-target-cpu" "x86-64" -fsyntax-only -verify=scalar %s
+// RUN:"-target-cpu" "x86-64" -fsyntax-only -verify=scalar -Wno-unused %s
 // RUN: %clang_cc1 "-aux-triple" "x86_64-unknown-linux-gnu" "-triple" "nvptx64-nvidia-cuda" \
-// RUN:-fcuda-is-device "-aux-target-cpu" "x86-64" -fsyntax-only -verify=scalar %s
+// RUN:-fcuda-is-device "-aux-target-cpu" "x86-64" -fsyntax-only -verify=scalar -Wno-unused %s
 
 #include "Inputs/cuda.h"
 
 __device__ void test(bool b, __bf16 *out, __bf16 in) {
   __bf16 bf16 = in; // No error on using the type itself.
 
-  bf16 + bf16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
-  bf16 - bf16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
-  bf16 * bf16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
-  bf16 / bf16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
+  bf16 + bf16;
+  bf16 - bf16;
+  bf16 * bf16;
+  bf16 / bf16;
 
   __fp16 fp16;
 
-  bf16 + fp16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
-  fp16 + bf16; // scalar-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
-  bf16 - fp16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
-  fp16 - bf16; // scalar-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
-  bf16 * fp16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
-  fp16 * bf16; // scalar-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
-  bf16 / fp16; // scalar-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
-  fp16 / bf16; // scalar-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
+  bf16 + fp16;
+  fp16 + bf16;
+  bf16 - fp16;
+  fp16 - bf16;
+  bf16 * fp16;
+  fp16 * bf16;
+  bf16 / fp16;
+  fp16 / bf16;
   bf16 = fp16; // scalar-error {{assigning to '__bf16' from incompatible type '__fp16'}}
   fp16 = bf16; // scalar-error {{assigning to '__fp16' from incompatible type '__bf16'}}
-  bf16 + (b ? fp16 : bf16); // scalar-error {{incompatible operand typ

[PATCH] D150913: [Clang][Bfloat16] Upgrade __bf16 to arithmetic type, change mangling, and extend excess precision support.

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs added a comment.

Misc style improvement.




Comment at: clang/lib/AST/Type.cpp:2199
   if (const auto *BT = dyn_cast(CanonicalType))
-return BT->getKind() >= BuiltinType::Bool &&
-   BT->getKind() <= BuiltinType::Ibm128 &&
-   BT->getKind() != BuiltinType::BFloat16;
+  return BT->getKind() >= BuiltinType::Bool &&
+ BT->getKind() <= BuiltinType::Ibm128;

Remove the tab whitespace.



Comment at: clang/lib/Sema/SemaOverload.cpp:2051-2052
 FromType = ToType.getUnqualifiedType();
-  } else if (IsTransparentUnionStandardConversion(S, From, ToType,
- InOverloadResolution,
- SCS, CStyle)) {
+  } else if (IsTransparentUnionStandardConversion(
+ S, From, ToType, InOverloadResolution, SCS, CStyle)) {
 SCS.Second = ICK_TransparentUnionConversion;





Comment at: clang/test/Sema/arm-bfloat.cpp:45-55
+  a * b;
+  a / b;
+
+  a + c;
+  a - c;
+  a * c;
+  a / c;

Remove newline.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150913/new/

https://reviews.llvm.org/D150913

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names and adapt __bf16 to be arithmetic type

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs added a comment.

I have created a separate change to upgrade existing `__bf16` to arithmetic 
type at D150913 




Comment at: clang/lib/AST/Type.cpp:
+  return (BT->getKind() >= BuiltinType::Bool &&
+  BT->getKind() <= BuiltinType::Ibm128 &&
+  (BT->getKind() != BuiltinType::BFloat16 ||

Remove



Comment at: clang/lib/Basic/Targets/AMDGPU.h:122
+  const char *getBFloat16Mangling() const override { return "DF16b"; };
+  
   std::string_view getClobbers() const override { return ""; }

Remove


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names and introduce Bfloat16 arithmetic type.

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs added a comment.

In D149573#4309378 , @tschuett wrote:

> I don't believe that there is NativeBFloat16Type. AArch64 learned bf16 with 
> ARMv8.6-A, but very limited operations and only in SIMD. X86 supports bf16 
> since Cooperlake, but very limited operations and only in SIMD.
>
> Maybe GPUs?



In D149573#4309378 , @tschuett wrote:

> I don't believe that there is NativeBFloat16Type. AArch64 learned bf16 with 
> ARMv8.6-A, but very limited operations and only in SIMD. X86 supports bf16 
> since Cooperlake, but very limited operations and only in SIMD.
>
> Maybe GPUs?

Dear @tschuett,

Thank you for your input. It seems that NativeBFloat16Type is indeed limited in 
availability. As you mentioned, AArch64 and X86 offer some bf16 support, but 
only in SIMD and with limited operations. This flag is intended to guard 
changes for targets with full bf16 support, as discussed in this RFC: 
https://discourse.llvm.org/t/rfc-c-23-p1467r9-extended-floating-point-types-and-standard-names/70033/12.
 While few public targets currently have native bf16 support, this still serves 
as a useful precaution.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names and introduce Bfloat16 arithmetic type.

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs added inline comments.



Comment at: libcxxabi/test/test_demangle.pass.cpp:10921
 {"_ZNK5clang4Type10isRealTypeEv", "clang::Type::isRealType() const"},
-{"_ZNK5clang4Type16isArithmeticTypeEv", "clang::Type::isArithmeticType() 
const"},
+{"_ZNK5clang4Type16isArithmeticTypeEv", 
"clang::Type::isArithmeticType(clang::ASTContext&) const"},
 {"_ZNK5clang4Type12isScalarTypeEv", "clang::Type::isScalarType() const"},

Forgot to update the mangled name as these tests don't seem to run locally with 
cmake check-all 


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names and introduce Bfloat16 arithmetic type.

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs updated this revision to Diff 518468.
codemzs added a comment.
Herald added subscribers: mstorsjo, mgrang, fedor.sergeev.

Fix Clang format failures.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

Files:
  clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
  clang-tools-extra/clang-tidy/readability/SuspiciousCallArgumentCheck.cpp
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/BuiltinTypes.def
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Driver/Options.td
  clang/include/clang/Lex/LiteralSupport.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/SMTConv.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/Interp/ByteCodeExprGen.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/MicrosoftMangle.cpp
  clang/lib/AST/NSAPI.cpp
  clang/lib/AST/PrintfFormatString.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypeLoc.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/ARM.h
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CodeGenTypes.cpp
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Index/USRGeneration.cpp
  clang/lib/Lex/LiteralSupport.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaObjCProperty.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Serialization/ASTCommon.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/test/CodeGenCXX/cxx2b-fp-ext-std-names-p1467r9.cpp
  clang/test/Sema/cxx2b-fp-ext-std-names-p1467r9.cpp
  libcxxabi/test/test_demangle.pass.cpp

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names and introduce Bfloat16 arithmetic type.

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs added a comment.

My change to libcxxabi/test/test_demangle.pass.cpp (last file in the change) is 
one is only one line i.e 
{"_ZNK5clang4Type16isArithmeticTypeERNS_10ASTContextE", 
"clang::Type::isArithmeticType(clang::ASTContext&) const"}, but running 
clang-format on it changes bunch of lines.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names and introduce Bfloat16 arithmetic type.

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs added a comment.

In D149573#4310601 , @philnik wrote:

> In D149573#4310009 , @codemzs wrote:
>
>> My change to libcxxabi/test/test_demangle.pass.cpp (last file in the change) 
>> is only one line i.e {"_ZNK5clang4Type16isArithmeticTypeERNS_10ASTContextE", 
>> "clang::Type::isArithmeticType(clang::ASTContext&) const"}, but running 
>> clang-format on it changes bunch of lines.
>
> Please don't clang-format the test then. There is no need to do it, and the 
> changes look rather confusing. I don't really understand why you add it at 
> all TBH. This doesn't look like it tests anything from this patch.

@philnik Thank you for your feedback on the changes to 
`libcxxabi/test/test_demangle.pass.cpp`. I apologize for any confusion my 
initial approach may have caused. I intended to keep the test file consistent 
with the updated function prototype, but I understand your concern about 
clang-format's impact on readability.

I will revert the changes to the test file as you suggested, ensuring it does 
not affect the current patch's functionality. I appreciate your guidance and 
will consider these aspects in future updates.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names and introduce Bfloat16 arithmetic type.

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs marked 10 inline comments as done.
codemzs added a comment.

Addressing @erichkeane 's review comments and pushing out the updated patch.




Comment at: clang/include/clang/Basic/LangOptions.def:468
 
+LANGOPT(ExperimentalNewItaniumMangling, 1, 0, "experimental new Itanium 
mangling")
+

erichkeane wrote:
> I'm not sure I like the implications or maintainability of this.  This is 
> something that is likely to get out of hand too quickly.  We probably need to 
> just figure out what the itanium mangling is GOING to be (perhaps @rjmccall 
> has some  insight?), and just implement that.
> 
> Also, this isn't really a 'Language Option', so much as a codegen option.
Thank you for your valuable feedback. Based on your suggestion and considering 
that GCC has already implemented the mangling as `DF16b`, I agree that if we 
have reasonable confidence in the direction the mangling will take, it would be 
better to implement it directly instead of guarding it with an experimental 
flag. Therefore, I will be removing the flag. I initially added the flag since 
@tahonermann was on board with implementing the bf16 arithmetic type, assuming 
the mangling was finalized.

However, I understand your concerns and would appreciate further input from 
both @tahonermann and @rjmccall on this matter. My intention is to avoid 
stalling the progress of this change due to mangling finalization.

I'm open to further discussion and collaboration to ensure we make the right 
decision for our project while maintaining the momentum of the review process.



Comment at: clang/lib/AST/ASTContext.cpp:7152
+  RHSKind = RHS->castAs()->getKind();
+auto comp = CXX23FloatingPointConversionRankMap[LHSKind][RHSKind];
+return comp;

erichkeane wrote:
> by coding standard, you can't use 'auto' here.  Also, variables are capital. 
> I probably just would return it without the intermediary variable.
> 
> That said, this is exactly what I feared the unordered-map table above was 
> for.  We need to come up with a better storage medium for that.
> 
> My thought is to introduce something like:
> 
> ```
> constexpr unsigned FloatRankToIndex(clang::BuiltinType::Kind) {
>   switch(Kind) {
> case clang::BuiltinType::Float16: return 0;  
> case clang::BuiltinType::BF16: return 1;
> case clang::BuiltinType::Float: return 2;
> case clang::BuiltinType::Double: return 3;
> case clang::BuiltinType::LongDouble: return 4;
> default: llvm_unreachable("Not a floating builtin type");
>  }
> ```
> And just run that on `LHSKind` and `RHSKind` here.  Then, the 
> `CXX23FloatingPointConversionRankMap` can be just a 2d pair of arrays:
> 
> 
> 
> ```
> std::array, 5> 
> CXX23FloatingPointConversionRankMap = 
> ```
> 
> We get the same results with very small runtime cost (for the 2 switches per 
> operation), but save two `unordered_map` lookups, AND save the runtime 
> construction of the `unordered_map`s.
Thank you for your insightful suggestion! I agree that using a 2D array along 
with the `FloatRankToIndex` function is a more efficient and cleaner approach. 
I've updated the implementation accordingly. I appreciate your guidance on this.



Comment at: clang/test/CodeGenCXX/cxx2b-fp-ext-std-names-p1467r9.cpp:5
+// CHECK-LABEL: @_Z1fDF16b(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[V_ADDR:%.*]] = alloca bfloat, align 2

erichkeane wrote:
> `entry` isn't a stable name here, so you shouldn't use this label.
I have removed the "entry" label as you suggested.

Just to let you know, this label was automatically generated by the script 
`utils/update_cc_test_checks.py`, which is used to update the expected output 
of the test cases. I noticed that this label is present in other tests in the 
codebase as well.

Out of curiosity, why is this label not considered stable?



Comment at: clang/test/CodeGenCXX/cxx2b-fp-ext-std-names-p1467r9.cpp:101
+
+// CHECK-LABEL: @_Z4testv(
+// CHECK-NEXT:  entry:

erichkeane wrote:
> I'd vastly prefer these check-next commands be interlaced in teh code, so it 
> is easy to see which line is supposed to associate with which.
I understand your preference for interlacing `CHECK-NEXT` commands with the 
code to improve readability. Unfortunately, the update_cc_test_checks.py script 
doesn't seem have an option to interlace `CHECK-NEXT` statements, and it can be 
challenging to achieve this in certain scenarios, such as when we have multiple 
loads followed by stores.

To address your concern, I've refactored the test code into smaller functions, 
which should make it easier to read and understand the relationship between the 
code and the corresponding `CHECK` statements. I hope this improves the 
readability and addresses your concerns. If you have any further suggestions or 
improvements, please don't hesitate to let me know. I'm open to making any 
necessary changes to e

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names and introduce Bfloat16 arithmetic type.

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs added a comment.

Thank you @erichkeane for your insightful review. I have addressed the feedback 
from your previous review.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs added a comment.

In D149573#4395968 , @erichkeane 
wrote:

> This all LGTM, but I want @tahonermann to do a pass as well, he knows more 
> about FP than I do, so I don't want to accept without his run-through.

Thank you, @erichkeane for the review. @aaron.ballman if you can please also 
have a look when you get a chance it would be great!

@tahonermann Just a quick note - I've made the changes you initially suggested 
in the RFC 
.
 When you get a chance, could you have another look?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs updated this revision to Diff 529171.
codemzs marked 4 inline comments as done.
codemzs set the repository for this revision to rG LLVM Github Monorepo.
codemzs added a comment.

Hi @tahonermann,

Thank you for your insights on the patch. I concur with your perspective about 
the potential brittleness of comparison operations on the 
`FloatingRankCompareResult` enum type. As a remedy, I have incorporated a 
helper routine to handle such operations.

Regarding the `getFloatingTypeOrder()`method, it employs a 2-D grid to evaluate 
the conversion rank between two types. The grid index for a type is firmly 
established in the `CXX23FloatRankToIndex`, offering a stable indexing 
mechanism. Hence, it appears that this approach mitigates the brittleness 
concern associated with the comparison of `FloatingRankCompareResult` enum 
values.

I'm open to further insights if there are aspects I may have overlooked.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Lex/LiteralSupport.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/SMTConv.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/Type.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Lex/LiteralSupport.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CodeGenCXX/cxx23-fp-ext-std-names-p1467r9.cpp
  clang/test/CodeGenCXX/cxx23-vector-bfloat16.cpp
  clang/test/Sema/cxx23-fp-ext-std-names-p1467r9.cpp

Index: clang/test/Sema/cxx23-fp-ext-std-names-p1467r9.cpp
===
--- /dev/null
+++ clang/test/Sema/cxx23-fp-ext-std-names-p1467r9.cpp
@@ -0,0 +1,465 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++23 -target-feature +fullbf16 -verify -ast-dump %s | FileCheck %s
+
+_Float16 f16_val_1 = 1.0bf16; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type '__bf16'}}
+_Float16 f16_val_2 = 1.0f; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type 'float'}}
+_Float16 f16_val_3 = 1.0; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type 'double'}}
+_Float16 f16_val_4 = 1.0l; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalue of type 'long double'}}
+_Float16 f16_val_6 = 1.0f16;
+//CHECK:  VarDecl {{.*}} f16_val_6 '_Float16' cinit
+//CHECK-NEXT: FloatingLiteral {{.*}} '_Float16' 1.00e+00
+_Float16 f16_val_7 = static_cast<_Float16>(1.0bf16); // expected-error {{static_cast from '__bf16' to '_Float16' is not allowed}}
+_Float16 f16_val_8 = static_cast<_Float16>(1.0f);
+//CHECK:  VarDecl {{.*}} f16_val_8 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'float' 1.00e+00
+_Float16 f16_val_9 = static_cast<_Float16>(1.0);
+//CHECK:  VarDecl {{.*}} f16_val_9 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'double' 1.00e+00
+_Float16 f16_val_10 = static_cast<_Float16>(1.0l);
+//CHECK:  VarDecl {{.*}} f16_val_10 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} 'long double' 1.00e+00
+_Float16 f16_val_11 = static_cast<_Float16>(1.0f16);
+//CHECK:  VarDecl {{.*}} f16_val_11 '_Float16' cinit
+//CHECK-NEXT: CXXStaticCastExpr {{.*}} '_Float16' static_cast<_Float16> 
+//CHECK-NEXT: FloatingLiteral {{.*}} '_Float16' 1.00e+00
+
+decltype(0.0BF16) bf16_val_1 = 1.0f16; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type '_Float16'}}
+decltype(0.0BF16) bf16_val_2 = 1.0f; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type 'float'}}
+decltype(0.0BF16) bf16_val_3 = 1.0; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type 'double'}}
+decltype(0.0BF16) bf16_val_4 = 1.0l; // expected-error {{cannot initialize a variable of type 'decltype(0.BF16)' (aka '__bf16') with an rvalue of type 'long double'}}
+decltype(0.0BF16) bf16_val_5 = 1.0bf16;
+//CHECK:  VarDecl {{.*}} bf16_val_5 'decltype(0.BF16)':'__bf16' cinit
+//CHECK-NEXT: FloatingLiteral {{.*}} '__bf16' 1.00e+00
+
+decltype(0.0BF16) bf16_val_6 = static_cast(1.0f16); // expected-error {{static_cast from '_Float16' to 'decltype(0.BF16)' (aka '__bf16') is not allowed}}
+decltype(0.0BF16) bf16_val_7 = static_cast(1.0f);
+//CHECK:  VarDecl {{.*}} bf16_val_7 'decltype(0.BF16)':

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs added inline comments.



Comment at: clang/lib/Sema/SemaCast.cpp:1367
+  Self.Context.doCXX23ExtendedFpTypesRulesApply(DestType, SrcType)) {
+// Support for cast between fp16 and bf16 doesn't exist yet.
+if (!((DestType->isBFloat16Type() || DestType->isFloat16Type()) &&

tahonermann wrote:
> Should this be a FIXME comment? What happens in this case? Should we perhaps 
> assert on such attempted conversions?
I have added the FIXME. There is a test case for this scenario:

```_Float16 f16_val_7 = static_cast<_Float16>(1.0bf16); // expected-error 
{{static_cast from '__bf16' to '_Float16' is not allowed}}```

If you still believe it might be better to add an assert I can do that, please 
let me know.



Comment at: clang/lib/Sema/SemaExpr.cpp:1235-1237
+if (order == FRCR_Unordered) {
+  return QualType();
+}

tahonermann wrote:
> Return of an invalid type is a new behavior for this function and it isn't 
> clear to me that callers will handle it (or be expected to handle it) such 
> that a diagnostic will be generated. Perhaps a diagnostic should be issued 
> here? Or perhaps this should be an assertion?
It results in an error, please see the below test case:

```auto f16_bf16 = 1.0f16 + 1.0bf16; // expected-error {{invalid operands to 
binary expression ('_Float16' and '__bf16')}}```

This function is only called by `UsualArithmeticConversions` which returns 
invalid type in several places, hence returning invalid type should be ok? If 
you still prefer an assertion or diagnostic, I will happily add one.



Comment at: clang/lib/Sema/SemaOverload.cpp:4202
+  if (S.Context.getFloatingTypeOrder(SCS2.getToType(1),
+ SCS1.getFromType()) < FRCR_Equal) 
{
+return ImplicitConversionSequence::Better;

tahonermann wrote:
> This comparison includes `FRCR_Unordered`, is that intended? (another case at 
> line 4225 below)
Yes, my understanding is we are checking if the second sequence's type's (T3) 
conversion rank is not equal to the conversion rank of FP2. Is that not correct?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D149573: [Clang][C++23] Implement core language changes from P1467R9 extended floating-point types and standard names

[M. Zeeshan Siddiqui via Phabricator via cfe-commits]

codemzs added a comment.

@tahonermann Gentle ping, please let me know if you have any questions.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149573/new/

https://reviews.llvm.org/D149573

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits