[clang] [HLSL] Vector vector standard conversions (PR #71098)

[Chris B via cfe-commits]

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/71098

>From 6bf40beff47c6bfcc73ce4c5d75bd47b52e6959c Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Wed, 1 Nov 2023 12:18:43 -0500
Subject: [PATCH] [HLSL] Vector vector standard conversions

HLSL supports vector truncation and element conversions as part of
standard conversion sequences. The vector truncation conversion is a C++
second conversion in the conversion sequence. If a vector truncation is
in a conversion sequence an element conversion may occur after it before
the standard C++ third conversion.

Vector element conversions can be boolean conversions, floating point or
integral conversions or promotions.

[HLSL Draft
Specification](https://microsoft.github.io/hlsl-specs/specs/hlsl.pdf)

../clang/test/CodeGenHLSL/BasicFeatures/standard_conversion_sequences.hl
sl
../clang/test/SemaHLSL/BuiltIns/vector-constructors-erros.hlsl
../clang/test/SemaHLSL/standard_conversion_sequences.hlsl
---
 clang/include/clang/AST/OperationKinds.def|   3 +
 .../clang/Basic/DiagnosticSemaKinds.td|   3 +
 clang/include/clang/Sema/Overload.h   |  12 +-
 clang/lib/AST/Expr.cpp|   1 +
 clang/lib/AST/ExprConstant.cpp|   2 +
 clang/lib/CodeGen/CGExpr.cpp  |   2 +
 clang/lib/CodeGen/CGExprAgg.cpp   |   2 +
 clang/lib/CodeGen/CGExprComplex.cpp   |   1 +
 clang/lib/CodeGen/CGExprConstant.cpp  |   1 +
 clang/lib/CodeGen/CGExprScalar.cpp|  23 +-
 clang/lib/Edit/RewriteObjCFoundationAPI.cpp   |   4 +
 clang/lib/Sema/SemaChecking.cpp   |  11 +-
 clang/lib/Sema/SemaExprCXX.cpp|  84 ++
 clang/lib/Sema/SemaInit.cpp   |   2 +-
 clang/lib/Sema/SemaOverload.cpp   | 253 +++---
 clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp |   3 +-
 .../standard_conversion_sequences.hlsl| 119 
 .../BuiltIns/vector-constructors-erros.hlsl   |   2 +-
 .../standard_conversion_sequences.hlsl|  92 +++
 19 files changed, 510 insertions(+), 110 deletions(-)
 create mode 100644 
clang/test/CodeGenHLSL/BasicFeatures/standard_conversion_sequences.hlsl
 create mode 100644 clang/test/SemaHLSL/standard_conversion_sequences.hlsl

diff --git a/clang/include/clang/AST/OperationKinds.def 
b/clang/include/clang/AST/OperationKinds.def
index 8dd98730dff7426..e497fe4d1f93ff4 100644
--- a/clang/include/clang/AST/OperationKinds.def
+++ b/clang/include/clang/AST/OperationKinds.def
@@ -361,6 +361,9 @@ CAST_OPERATION(AddressSpaceConversion)
 // Convert an integer initializer to an OpenCL sampler.
 CAST_OPERATION(IntToOCLSampler)
 
+// Truncate a vector type (HLSL only).
+CAST_OPERATION(VectorTruncation)
+
 //===- Binary Operations  
-===//
 // Operators listed in order of precedence.
 // Note that additions to this should also update the StmtVisitor class,
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 4614324babb1c91..8ae509168cf17f6 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -12004,6 +12004,9 @@ def err_hlsl_pointers_unsupported : Error<
 def err_hlsl_operator_unsupported : Error<
   "the '%select{&|*|->}0' operator is unsupported in HLSL">;
 
+def warn_hlsl_impcast_vector_truncation : Warning<
+  "implicit conversion truncates vector: %0 to %1">, InGroup;
+
 // Layout randomization diagnostics.
 def err_non_designated_init_used : Error<
   "a randomized struct can only be initialized with a designated initializer">;
diff --git a/clang/include/clang/Sema/Overload.h 
b/clang/include/clang/Sema/Overload.h
index a97968dc7b20967..0d4aaa5ff7c766b 100644
--- a/clang/include/clang/Sema/Overload.h
+++ b/clang/include/clang/Sema/Overload.h
@@ -192,6 +192,9 @@ class Sema;
 /// C-only conversion between pointers with incompatible types
 ICK_Incompatible_Pointer_Conversion,
 
+/// HLSL vector truncation.
+ICK_HLSL_Vector_Truncation,
+
 /// The number of conversion kinds
 ICK_Num_Conversion_Kinds,
   };
@@ -271,6 +274,12 @@ class Sema;
 /// pointer-to-member conversion, or boolean conversion.
 ImplicitConversionKind Second : 8;
 
+/// Element - Between the second and third conversion a vector or matrix
+/// element conversion may occur. If this is not ICK_Identity this
+/// conversion is applied element-wise to each element in the vector or
+/// matrix.
+ImplicitConversionKind Element : 8;
+
 /// Third - The third conversion can be a qualification conversion
 /// or a function conversion.
 ImplicitConversionKind Third : 8;
@@ -357,7 +366,8 @@ class Sema;
 void setAsIdentityConversion();
 
 bool isIdentityConversion() const {
-  return Second == ICK_Identity && Third == ICK_Identity;
+  return Second == ICK_Identity && Ele

[clang] Avoid copying Param and Constr (PR #65488)

[Chris B via cfe-commits]

https://github.com/llvm-beanz approved this pull request.


https://github.com/llvm/llvm-project/pull/65488
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Support vector swizzles on scalars (PR #67700)

[Chris B via cfe-commits]

llvm-beanz wrote:

@cor3ntin, I've in parallel been working on fleshing out the immediately 
relevant bits of our language spec. This PR describes the _pp-number_ and 
_vector-literal_ grammars roughly correctly to this change.

I think I've addressed all the other feedback on the PR, please let me know if 
there's anything else you think I should change.

https://github.com/llvm/llvm-project/pull/67700
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Document runtime config directory options (PR #66593)

[Chris B via cfe-commits]

https://github.com/llvm-beanz approved this pull request.


https://github.com/llvm/llvm-project/pull/66593
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang-tools-extra] [flang] [compiler-rt] [clang] GitHub learn (PR #66806)

[Chris B via cfe-commits]

https://github.com/llvm-beanz approved this pull request.

Please make sure the commit title and description are updated before merging, 
but this looks good.

https://github.com/llvm/llvm-project/pull/66806
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [docs] Remove Visual Studio 2017 references and bump VS 2019 to VS 2022 (PR #70759)

[Chris B via cfe-commits]

https://github.com/llvm-beanz approved this pull request.


https://github.com/llvm/llvm-project/pull/70759
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Vector standard conversions (PR #71098)

[Chris B via cfe-commits]

https://github.com/llvm-beanz edited 
https://github.com/llvm/llvm-project/pull/71098
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Only build static analyzer sources if requested (PR #71653)

[Chris B via cfe-commits]

@@ -23,7 +23,9 @@ add_subdirectory(Tooling)
 add_subdirectory(DirectoryWatcher)
 add_subdirectory(Index)
 add_subdirectory(IndexSerialization)
-add_subdirectory(StaticAnalyzer)
+if(CLANG_ENABLE_STATIC_ANALYZER)

llvm-beanz wrote:

This approach slightly bothers me. One of the mistakes I think we (and by we I 
mean me) have made in the build system is allowing lots of things to be 
disabled from the configuration.

In general I think it is desirable to build and test code always, but to 
support modularity in what gets built into the final products.

I realize there is some contention between that approach having fast build and 
test cycles, but the tradeoff between fast and adequate coverage is not always 
an easy line to draw.

(cc @petrhosek & @smeenai)

https://github.com/llvm/llvm-project/pull/71653
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Parameter modifier parsing and AST (PR #72139)

[Chris B via cfe-commits]

https://github.com/llvm-beanz created 
https://github.com/llvm/llvm-project/pull/72139

This change implements parsing for HLSL's parameter modifier keywords `in`, 
`out` and `inout`. Because HLSL doesn't support references or pointers, these 
keywords are used to allow parameters to be passed in and out of functions.

This change only implements the parsing and AST support. In the HLSL ASTs we 
represent `out` and `inout` parameters as references, and we implement the 
semantics of by-value passing during IR generation.

In HLSL parameters marked `out` and `inout` are ambiguous in function 
declarations, and `in`, `out` and `inout` may be ambiguous at call sites.

This means a function may be defined as `fn(in T)` and `fn(inout T)` or `fn(out 
T)`, but not `fn(inout T)` and `fn(out T)`. If a funciton `fn` is declared with 
`in` and `inout` or `out` arguments, the call will be ambiguous the same as a 
C++ call would be ambiguous given declarations `fn(T)` and `fn(T&)`.

Fixes #59849

>From b99d291f99805bc090b8e51b8f8ad176a7cdd642 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Mon, 13 Nov 2023 11:14:06 -0600
Subject: [PATCH] [HLSL] Parameter modifier parsing and AST

This change implements parsing for HLSL's parameter modifier keywords
`in`, `out` and `inout`. Because HLSL doesn't support references or
pointers, these keywords are used to allow parameters to be passed in
and out of functions.

This change only implements the parsing and AST support. In the HLSL
ASTs we represent `out` and `inout` parameters as references, and we
implement the semantics of by-value passing during IR generation.

In HLSL parameters marked `out` and `inout` are ambiguous in function
declarations, and `in`, `out` and `inout` may be ambiguous at call
sites.

This means a function may be defined as `fn(in T)` and `fn(inout T)` or
`fn(out T)`, but not `fn(inout T)` and `fn(out T)`. If a funciton `fn`
is declared with `in` and `inout` or `out` arguments, the call will be
ambiguous the same as a C++ call would be ambiguous given declarations
`fn(T)` and `fn(T&)`.
---
 clang/include/clang/Basic/Attr.td | 12 
 clang/include/clang/Basic/AttrDocs.td | 19 ++
 .../clang/Basic/DiagnosticSemaKinds.td|  4 ++
 clang/include/clang/Basic/TokenKinds.def  |  3 +
 clang/include/clang/Sema/Sema.h   |  2 +
 clang/lib/AST/TypePrinter.cpp |  4 ++
 clang/lib/Parse/ParseDecl.cpp | 14 +++-
 clang/lib/Parse/ParseTentative.cpp|  3 +
 clang/lib/Sema/SemaDecl.cpp   | 21 ++
 clang/lib/Sema/SemaDeclAttr.cpp   | 33 ++
 clang/lib/Sema/SemaType.cpp   | 13 
 clang/test/SemaHLSL/parameter_modifiers.hlsl  | 64 +++
 .../SemaHLSL/parameter_modifiers_ast.hlsl | 36 +++
 13 files changed, 227 insertions(+), 1 deletion(-)
 create mode 100644 clang/test/SemaHLSL/parameter_modifiers.hlsl
 create mode 100644 clang/test/SemaHLSL/parameter_modifiers_ast.hlsl

diff --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 31434565becaec6..01eb0c3f9290780 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -4229,6 +4229,18 @@ def HLSLGroupSharedAddressSpace : TypeAttr {
   let Documentation = [HLSLGroupSharedAddressSpaceDocs];
 }
 
+def HLSLParamModifier : TypeAttr {
+  let Spellings = [CustomKeyword<"in">, CustomKeyword<"inout">, 
CustomKeyword<"out">];
+  let Accessors = [Accessor<"isIn", [CustomKeyword<"in">]>,
+   Accessor<"isInOut", [CustomKeyword<"inout">]>,
+   Accessor<"isOut", [CustomKeyword<"out">]>,
+   Accessor<"isAnyOut", [CustomKeyword<"out">, 
CustomKeyword<"inout">]>,
+   Accessor<"isAnyIn", [CustomKeyword<"in">, 
CustomKeyword<"inout">]>];
+  let Subjects = SubjectList<[ParmVar]>;
+  let Documentation = [HLSLParamQualifierDocs];
+  let Args = [DefaultBoolArgument<"MergedSpelling", /*default*/0, /*fake*/1>];
+}
+
 def RandomizeLayout : InheritableAttr {
   let Spellings = [GCC<"randomize_layout">];
   let Subjects = SubjectList<[Record]>;
diff --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index fa6f6acd0c30e88..09090c94ae7fb73 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -7061,6 +7061,25 @@ The full documentation is available here: 
https://learn.microsoft.com/en-us/wind
   }];
 }
 
+def HLSLParamQualifierDocs : Documentation {
+  let Category = DocCatVariable;
+  let Content = [{
+HLSL function parameters are passed by value. Parameter declarations support
+three qualifiers to denote parameter passing behavior. The three qualifiers are
+`in`, `out` and `inout`.
+
+Parameters annotated with `in` or with no annotation are passed by value from
+the caller to the callee.
+
+Parameters annotated with `out` are written to the argument after the callee
+returns (

[clang] [HLSL] Support vector swizzles on scalars (PR #67700)

[Chris B via cfe-commits]

llvm-beanz wrote:

Friendly ping @AaronBallman & @cor3ntin.

https://github.com/llvm/llvm-project/pull/67700
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Parameter modifier parsing and AST (PR #72139)

[Chris B via cfe-commits]

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/72139

>From 8be56542f25b08ee5d6a325f76d12c28c4a366d7 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Mon, 13 Nov 2023 11:14:06 -0600
Subject: [PATCH] [HLSL] Parameter modifier parsing and AST

This change implements parsing for HLSL's parameter modifier keywords
`in`, `out` and `inout`. Because HLSL doesn't support references or
pointers, these keywords are used to allow parameters to be passed in
and out of functions.

This change only implements the parsing and AST support. In the HLSL
ASTs we represent `out` and `inout` parameters as references, and we
implement the semantics of by-value passing during IR generation.

In HLSL parameters marked `out` and `inout` are ambiguous in function
declarations, and `in`, `out` and `inout` may be ambiguous at call
sites.

This means a function may be defined as `fn(in T)` and `fn(inout T)` or
`fn(out T)`, but not `fn(inout T)` and `fn(out T)`. If a funciton `fn`
is declared with `in` and `inout` or `out` arguments, the call will be
ambiguous the same as a C++ call would be ambiguous given declarations
`fn(T)` and `fn(T&)`.
---
 clang/include/clang/Basic/Attr.td | 12 
 clang/include/clang/Basic/AttrDocs.td | 19 ++
 .../clang/Basic/DiagnosticSemaKinds.td|  4 ++
 clang/include/clang/Basic/TokenKinds.def  |  3 +
 clang/include/clang/Sema/Sema.h   |  3 +
 clang/lib/AST/TypePrinter.cpp |  4 ++
 clang/lib/Parse/ParseDecl.cpp | 14 +++-
 clang/lib/Parse/ParseTentative.cpp|  3 +
 clang/lib/Sema/SemaDecl.cpp   | 20 ++
 clang/lib/Sema/SemaDeclAttr.cpp   | 33 ++
 clang/lib/Sema/SemaType.cpp   | 13 
 clang/test/SemaHLSL/parameter_modifiers.hlsl  | 64 +++
 .../SemaHLSL/parameter_modifiers_ast.hlsl | 36 +++
 13 files changed, 227 insertions(+), 1 deletion(-)
 create mode 100644 clang/test/SemaHLSL/parameter_modifiers.hlsl
 create mode 100644 clang/test/SemaHLSL/parameter_modifiers_ast.hlsl

diff --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 31434565becaec6..01eb0c3f9290780 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -4229,6 +4229,18 @@ def HLSLGroupSharedAddressSpace : TypeAttr {
   let Documentation = [HLSLGroupSharedAddressSpaceDocs];
 }
 
+def HLSLParamModifier : TypeAttr {
+  let Spellings = [CustomKeyword<"in">, CustomKeyword<"inout">, 
CustomKeyword<"out">];
+  let Accessors = [Accessor<"isIn", [CustomKeyword<"in">]>,
+   Accessor<"isInOut", [CustomKeyword<"inout">]>,
+   Accessor<"isOut", [CustomKeyword<"out">]>,
+   Accessor<"isAnyOut", [CustomKeyword<"out">, 
CustomKeyword<"inout">]>,
+   Accessor<"isAnyIn", [CustomKeyword<"in">, 
CustomKeyword<"inout">]>];
+  let Subjects = SubjectList<[ParmVar]>;
+  let Documentation = [HLSLParamQualifierDocs];
+  let Args = [DefaultBoolArgument<"MergedSpelling", /*default*/0, /*fake*/1>];
+}
+
 def RandomizeLayout : InheritableAttr {
   let Spellings = [GCC<"randomize_layout">];
   let Subjects = SubjectList<[Record]>;
diff --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index fa6f6acd0c30e88..09090c94ae7fb73 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -7061,6 +7061,25 @@ The full documentation is available here: 
https://learn.microsoft.com/en-us/wind
   }];
 }
 
+def HLSLParamQualifierDocs : Documentation {
+  let Category = DocCatVariable;
+  let Content = [{
+HLSL function parameters are passed by value. Parameter declarations support
+three qualifiers to denote parameter passing behavior. The three qualifiers are
+`in`, `out` and `inout`.
+
+Parameters annotated with `in` or with no annotation are passed by value from
+the caller to the callee.
+
+Parameters annotated with `out` are written to the argument after the callee
+returns (Note: arguments values passed into `out` parameters _are not_ copied
+into the callee).
+
+Parameters annotated with `inout` are copied into the callee via a temporary,
+and copied back to the argument after the callee returns.
+  }];
+}
+
 def AnnotateTypeDocs : Documentation {
   let Category = DocCatType;
   let Heading = "annotate_type";
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 4614324babb1c91..313acc3499e3ffc 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -11989,6 +11989,7 @@ def err_hlsl_numthreads_argument_oor : Error<"argument 
'%select{X|Y|Z}0' to numt
 def err_hlsl_numthreads_invalid : Error<"total number of threads cannot exceed 
%0">;
 def err_hlsl_missing_numthreads : Error<"missing numthreads attribute for %0 
shader entry">;
 def err_

[clang] [clang] Only build static analyzer sources if requested (PR #71653)

[Chris B via cfe-commits]

@@ -23,7 +23,9 @@ add_subdirectory(Tooling)
 add_subdirectory(DirectoryWatcher)
 add_subdirectory(Index)
 add_subdirectory(IndexSerialization)
-add_subdirectory(StaticAnalyzer)
+if(CLANG_ENABLE_STATIC_ANALYZER)

llvm-beanz wrote:

> Well yes, but I'm not introducing the option here, I'm just making it work.

My argument here would be that if the option doesn't work, maybe we shouldn't 
fix it. In particular I think having the static analyzer be conditional in the 
testing tools makes for a more complicated testing matrix. If you disable the 
static analyzer in the build you also need to disable it in the testing tools 
and the test cases.

This becomes a more complicated issue because changes in the AST library can 
impact correctness of the static analyzer, so should we really be supporting 
disabling the static analyzer from the testing?

It seems to me that we should maybe support `CLANG_ENABLE_STATIC_ANALYZER` as a 
way to remove the static analyzer from the clang built product, but not from 
the build, testing tools, or test cases.

https://github.com/llvm/llvm-project/pull/71653
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Vector standard conversions (PR #71098)

[Chris B via cfe-commits]

llvm-beanz wrote:

@rjmccall & @efriedma-quic, do the CodeGen changes here look okay to you?

https://github.com/llvm/llvm-project/pull/71098
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Parameter modifier parsing and AST (PR #72139)

[Chris B via cfe-commits]

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/72139

>From 8be56542f25b08ee5d6a325f76d12c28c4a366d7 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Mon, 13 Nov 2023 11:14:06 -0600
Subject: [PATCH 1/2] [HLSL] Parameter modifier parsing and AST

This change implements parsing for HLSL's parameter modifier keywords
`in`, `out` and `inout`. Because HLSL doesn't support references or
pointers, these keywords are used to allow parameters to be passed in
and out of functions.

This change only implements the parsing and AST support. In the HLSL
ASTs we represent `out` and `inout` parameters as references, and we
implement the semantics of by-value passing during IR generation.

In HLSL parameters marked `out` and `inout` are ambiguous in function
declarations, and `in`, `out` and `inout` may be ambiguous at call
sites.

This means a function may be defined as `fn(in T)` and `fn(inout T)` or
`fn(out T)`, but not `fn(inout T)` and `fn(out T)`. If a funciton `fn`
is declared with `in` and `inout` or `out` arguments, the call will be
ambiguous the same as a C++ call would be ambiguous given declarations
`fn(T)` and `fn(T&)`.
---
 clang/include/clang/Basic/Attr.td | 12 
 clang/include/clang/Basic/AttrDocs.td | 19 ++
 .../clang/Basic/DiagnosticSemaKinds.td|  4 ++
 clang/include/clang/Basic/TokenKinds.def  |  3 +
 clang/include/clang/Sema/Sema.h   |  3 +
 clang/lib/AST/TypePrinter.cpp |  4 ++
 clang/lib/Parse/ParseDecl.cpp | 14 +++-
 clang/lib/Parse/ParseTentative.cpp|  3 +
 clang/lib/Sema/SemaDecl.cpp   | 20 ++
 clang/lib/Sema/SemaDeclAttr.cpp   | 33 ++
 clang/lib/Sema/SemaType.cpp   | 13 
 clang/test/SemaHLSL/parameter_modifiers.hlsl  | 64 +++
 .../SemaHLSL/parameter_modifiers_ast.hlsl | 36 +++
 13 files changed, 227 insertions(+), 1 deletion(-)
 create mode 100644 clang/test/SemaHLSL/parameter_modifiers.hlsl
 create mode 100644 clang/test/SemaHLSL/parameter_modifiers_ast.hlsl

diff --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 31434565becaec6..01eb0c3f9290780 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -4229,6 +4229,18 @@ def HLSLGroupSharedAddressSpace : TypeAttr {
   let Documentation = [HLSLGroupSharedAddressSpaceDocs];
 }
 
+def HLSLParamModifier : TypeAttr {
+  let Spellings = [CustomKeyword<"in">, CustomKeyword<"inout">, 
CustomKeyword<"out">];
+  let Accessors = [Accessor<"isIn", [CustomKeyword<"in">]>,
+   Accessor<"isInOut", [CustomKeyword<"inout">]>,
+   Accessor<"isOut", [CustomKeyword<"out">]>,
+   Accessor<"isAnyOut", [CustomKeyword<"out">, 
CustomKeyword<"inout">]>,
+   Accessor<"isAnyIn", [CustomKeyword<"in">, 
CustomKeyword<"inout">]>];
+  let Subjects = SubjectList<[ParmVar]>;
+  let Documentation = [HLSLParamQualifierDocs];
+  let Args = [DefaultBoolArgument<"MergedSpelling", /*default*/0, /*fake*/1>];
+}
+
 def RandomizeLayout : InheritableAttr {
   let Spellings = [GCC<"randomize_layout">];
   let Subjects = SubjectList<[Record]>;
diff --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index fa6f6acd0c30e88..09090c94ae7fb73 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -7061,6 +7061,25 @@ The full documentation is available here: 
https://learn.microsoft.com/en-us/wind
   }];
 }
 
+def HLSLParamQualifierDocs : Documentation {
+  let Category = DocCatVariable;
+  let Content = [{
+HLSL function parameters are passed by value. Parameter declarations support
+three qualifiers to denote parameter passing behavior. The three qualifiers are
+`in`, `out` and `inout`.
+
+Parameters annotated with `in` or with no annotation are passed by value from
+the caller to the callee.
+
+Parameters annotated with `out` are written to the argument after the callee
+returns (Note: arguments values passed into `out` parameters _are not_ copied
+into the callee).
+
+Parameters annotated with `inout` are copied into the callee via a temporary,
+and copied back to the argument after the callee returns.
+  }];
+}
+
 def AnnotateTypeDocs : Documentation {
   let Category = DocCatType;
   let Heading = "annotate_type";
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 4614324babb1c91..313acc3499e3ffc 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -11989,6 +11989,7 @@ def err_hlsl_numthreads_argument_oor : Error<"argument 
'%select{X|Y|Z}0' to numt
 def err_hlsl_numthreads_invalid : Error<"total number of threads cannot exceed 
%0">;
 def err_hlsl_missing_numthreads : Error<"missing numthreads attribute for %0 
shader entry">;
 def 

[clang] [NFC] Cleanup and sort hlsl_intrinsics.h (PR #72414)

[Chris B via cfe-commits]

https://github.com/llvm-beanz created 
https://github.com/llvm/llvm-project/pull/72414

This is just a simple cleanup of hlsl_intrinsics.h. I've broken this into two 
commits to make it easier to follow during review. The first commit replaces 
the `__attribute__` annotations with preprocessor macros to make it easier to 
read the function declarations. The second commit sorts the function 
declarations.

Function declarations are sorted by function name alphabetically, then grouped 
by base element type. The declarations within each group are sorted in 
increasing order by number of elements, and the groups themselves are sorted by 
increasing element size. For elements of the same size they are then sorted by 
signed integers, then unsigned integers then floating point.

>From ec41437d8494f6af3ff49b926717b0152a0927cf Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Wed, 15 Nov 2023 09:25:01 -0600
Subject: [PATCH 1/2] [NFC] Use macros to simplify function attrs

This change just makes the header easier to read by replacing the
legacy attribute syntax with predefined macros.
---
 clang/lib/Headers/hlsl/hlsl_intrinsics.h | 566 ---
 1 file changed, 305 insertions(+), 261 deletions(-)

diff --git a/clang/lib/Headers/hlsl/hlsl_intrinsics.h 
b/clang/lib/Headers/hlsl/hlsl_intrinsics.h
index 22d9ec24e6a2104..4788b6113313555 100644
--- a/clang/lib/Headers/hlsl/hlsl_intrinsics.h
+++ b/clang/lib/Headers/hlsl/hlsl_intrinsics.h
@@ -11,556 +11,600 @@
 
 namespace hlsl {
 
-__attribute__((availability(shadermodel, introduced = 6.0)))
-__attribute__((clang_builtin_alias(__builtin_hlsl_wave_active_count_bits))) 
uint
-WaveActiveCountBits(bool bBit);
+#define _HLSL_BUILTIN_ALIAS(builtin)   
\
+  __attribute__((clang_builtin_alias(builtin)))
+#define _HLSL_AVAILABILITY(environment, version)   
\
+  __attribute__((availability(environment, introduced = version)))
 
+_HLSL_AVAILABILITY(shadermodel, 6.0)
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_wave_active_count_bits)
+uint WaveActiveCountBits(bool bBit);
+
+//===--===//
 // abs builtins
+//===--===//
 #ifdef __HLSL_ENABLE_16_BIT
-__attribute__((clang_builtin_alias(__builtin_elementwise_abs)))
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_abs)
 int16_t abs(int16_t);
-__attribute__((clang_builtin_alias(__builtin_elementwise_abs)))
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_abs)
 int16_t2 abs(int16_t2);
-__attribute__((clang_builtin_alias(__builtin_elementwise_abs)))
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_abs)
 int16_t3 abs(int16_t3);
-__attribute__((clang_builtin_alias(__builtin_elementwise_abs)))
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_abs)
 int16_t4 abs(int16_t4);
-__attribute__((clang_builtin_alias(__builtin_elementwise_abs))) half abs(half);
-__attribute__((clang_builtin_alias(__builtin_elementwise_abs)))
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_abs)
+half abs(half);
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_abs)
 half2 abs(half2);
-__attribute__((clang_builtin_alias(__builtin_elementwise_abs)))
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_abs)
 half3 abs(half3);
-__attribute__((clang_builtin_alias(__builtin_elementwise_abs)))
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_abs)
 half4 abs(half4);
 #endif
 
-__attribute__((clang_builtin_alias(__builtin_elementwise_abs))) int abs(int);
-__attribute__((clang_builtin_alias(__builtin_elementwise_abs))) int2 abs(int2);
-__attribute__((clang_builtin_alias(__builtin_elementwise_abs))) int3 abs(int3);
-__attribute__((clang_builtin_alias(__builtin_elementwise_abs))) int4 abs(int4);
-__attribute__((clang_builtin_alias(__builtin_elementwise_abs))) float
-abs(float);
-__attribute__((clang_builtin_alias(__builtin_elementwise_abs)))
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_abs)
+int abs(int);
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_abs)
+int2 abs(int2);
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_abs)
+int3 abs(int3);
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_abs)
+int4 abs(int4);
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_abs)
+float abs(float);
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_abs)
 float2 abs(float2);
-__attribute__((clang_builtin_alias(__builtin_elementwise_abs)))
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_abs)
 float3 abs(float3);
-__attribute__((clang_builtin_alias(__builtin_elementwise_abs)))
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_abs)
 float4 abs(float4);
-__attribute__((clang_builtin_alias(__builtin_elementwise_abs)))
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_abs)
 int64_t abs(int64_t);
-__attribute__((clang_builtin_alias(__builtin_elementwise_abs)))
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_abs)
 int64_t2 abs(int64_t2);
-__attribute__((clang_builtin_alias(__builtin_elementwise_abs)))
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_abs)
 int64_t3 abs(int64_t3);
-__attribute__((clang_builtin_al

[clang] [HLSL] Parameter modifier parsing and AST (PR #72139)

[Chris B via cfe-commits]

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/72139

>From 8be56542f25b08ee5d6a325f76d12c28c4a366d7 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Mon, 13 Nov 2023 11:14:06 -0600
Subject: [PATCH 1/3] [HLSL] Parameter modifier parsing and AST

This change implements parsing for HLSL's parameter modifier keywords
`in`, `out` and `inout`. Because HLSL doesn't support references or
pointers, these keywords are used to allow parameters to be passed in
and out of functions.

This change only implements the parsing and AST support. In the HLSL
ASTs we represent `out` and `inout` parameters as references, and we
implement the semantics of by-value passing during IR generation.

In HLSL parameters marked `out` and `inout` are ambiguous in function
declarations, and `in`, `out` and `inout` may be ambiguous at call
sites.

This means a function may be defined as `fn(in T)` and `fn(inout T)` or
`fn(out T)`, but not `fn(inout T)` and `fn(out T)`. If a funciton `fn`
is declared with `in` and `inout` or `out` arguments, the call will be
ambiguous the same as a C++ call would be ambiguous given declarations
`fn(T)` and `fn(T&)`.
---
 clang/include/clang/Basic/Attr.td | 12 
 clang/include/clang/Basic/AttrDocs.td | 19 ++
 .../clang/Basic/DiagnosticSemaKinds.td|  4 ++
 clang/include/clang/Basic/TokenKinds.def  |  3 +
 clang/include/clang/Sema/Sema.h   |  3 +
 clang/lib/AST/TypePrinter.cpp |  4 ++
 clang/lib/Parse/ParseDecl.cpp | 14 +++-
 clang/lib/Parse/ParseTentative.cpp|  3 +
 clang/lib/Sema/SemaDecl.cpp   | 20 ++
 clang/lib/Sema/SemaDeclAttr.cpp   | 33 ++
 clang/lib/Sema/SemaType.cpp   | 13 
 clang/test/SemaHLSL/parameter_modifiers.hlsl  | 64 +++
 .../SemaHLSL/parameter_modifiers_ast.hlsl | 36 +++
 13 files changed, 227 insertions(+), 1 deletion(-)
 create mode 100644 clang/test/SemaHLSL/parameter_modifiers.hlsl
 create mode 100644 clang/test/SemaHLSL/parameter_modifiers_ast.hlsl

diff --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 31434565becaec6..01eb0c3f9290780 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -4229,6 +4229,18 @@ def HLSLGroupSharedAddressSpace : TypeAttr {
   let Documentation = [HLSLGroupSharedAddressSpaceDocs];
 }
 
+def HLSLParamModifier : TypeAttr {
+  let Spellings = [CustomKeyword<"in">, CustomKeyword<"inout">, 
CustomKeyword<"out">];
+  let Accessors = [Accessor<"isIn", [CustomKeyword<"in">]>,
+   Accessor<"isInOut", [CustomKeyword<"inout">]>,
+   Accessor<"isOut", [CustomKeyword<"out">]>,
+   Accessor<"isAnyOut", [CustomKeyword<"out">, 
CustomKeyword<"inout">]>,
+   Accessor<"isAnyIn", [CustomKeyword<"in">, 
CustomKeyword<"inout">]>];
+  let Subjects = SubjectList<[ParmVar]>;
+  let Documentation = [HLSLParamQualifierDocs];
+  let Args = [DefaultBoolArgument<"MergedSpelling", /*default*/0, /*fake*/1>];
+}
+
 def RandomizeLayout : InheritableAttr {
   let Spellings = [GCC<"randomize_layout">];
   let Subjects = SubjectList<[Record]>;
diff --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index fa6f6acd0c30e88..09090c94ae7fb73 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -7061,6 +7061,25 @@ The full documentation is available here: 
https://learn.microsoft.com/en-us/wind
   }];
 }
 
+def HLSLParamQualifierDocs : Documentation {
+  let Category = DocCatVariable;
+  let Content = [{
+HLSL function parameters are passed by value. Parameter declarations support
+three qualifiers to denote parameter passing behavior. The three qualifiers are
+`in`, `out` and `inout`.
+
+Parameters annotated with `in` or with no annotation are passed by value from
+the caller to the callee.
+
+Parameters annotated with `out` are written to the argument after the callee
+returns (Note: arguments values passed into `out` parameters _are not_ copied
+into the callee).
+
+Parameters annotated with `inout` are copied into the callee via a temporary,
+and copied back to the argument after the callee returns.
+  }];
+}
+
 def AnnotateTypeDocs : Documentation {
   let Category = DocCatType;
   let Heading = "annotate_type";
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 4614324babb1c91..313acc3499e3ffc 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -11989,6 +11989,7 @@ def err_hlsl_numthreads_argument_oor : Error<"argument 
'%select{X|Y|Z}0' to numt
 def err_hlsl_numthreads_invalid : Error<"total number of threads cannot exceed 
%0">;
 def err_hlsl_missing_numthreads : Error<"missing numthreads attribute for %0 
shader entry">;
 def 

[clang] [HLSL] Parameter modifier parsing and AST (PR #72139)

[Chris B via cfe-commits]

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/72139

>From 8be56542f25b08ee5d6a325f76d12c28c4a366d7 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Mon, 13 Nov 2023 11:14:06 -0600
Subject: [PATCH 1/4] [HLSL] Parameter modifier parsing and AST

This change implements parsing for HLSL's parameter modifier keywords
`in`, `out` and `inout`. Because HLSL doesn't support references or
pointers, these keywords are used to allow parameters to be passed in
and out of functions.

This change only implements the parsing and AST support. In the HLSL
ASTs we represent `out` and `inout` parameters as references, and we
implement the semantics of by-value passing during IR generation.

In HLSL parameters marked `out` and `inout` are ambiguous in function
declarations, and `in`, `out` and `inout` may be ambiguous at call
sites.

This means a function may be defined as `fn(in T)` and `fn(inout T)` or
`fn(out T)`, but not `fn(inout T)` and `fn(out T)`. If a funciton `fn`
is declared with `in` and `inout` or `out` arguments, the call will be
ambiguous the same as a C++ call would be ambiguous given declarations
`fn(T)` and `fn(T&)`.
---
 clang/include/clang/Basic/Attr.td | 12 
 clang/include/clang/Basic/AttrDocs.td | 19 ++
 .../clang/Basic/DiagnosticSemaKinds.td|  4 ++
 clang/include/clang/Basic/TokenKinds.def  |  3 +
 clang/include/clang/Sema/Sema.h   |  3 +
 clang/lib/AST/TypePrinter.cpp |  4 ++
 clang/lib/Parse/ParseDecl.cpp | 14 +++-
 clang/lib/Parse/ParseTentative.cpp|  3 +
 clang/lib/Sema/SemaDecl.cpp   | 20 ++
 clang/lib/Sema/SemaDeclAttr.cpp   | 33 ++
 clang/lib/Sema/SemaType.cpp   | 13 
 clang/test/SemaHLSL/parameter_modifiers.hlsl  | 64 +++
 .../SemaHLSL/parameter_modifiers_ast.hlsl | 36 +++
 13 files changed, 227 insertions(+), 1 deletion(-)
 create mode 100644 clang/test/SemaHLSL/parameter_modifiers.hlsl
 create mode 100644 clang/test/SemaHLSL/parameter_modifiers_ast.hlsl

diff --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 31434565becaec6..01eb0c3f9290780 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -4229,6 +4229,18 @@ def HLSLGroupSharedAddressSpace : TypeAttr {
   let Documentation = [HLSLGroupSharedAddressSpaceDocs];
 }
 
+def HLSLParamModifier : TypeAttr {
+  let Spellings = [CustomKeyword<"in">, CustomKeyword<"inout">, 
CustomKeyword<"out">];
+  let Accessors = [Accessor<"isIn", [CustomKeyword<"in">]>,
+   Accessor<"isInOut", [CustomKeyword<"inout">]>,
+   Accessor<"isOut", [CustomKeyword<"out">]>,
+   Accessor<"isAnyOut", [CustomKeyword<"out">, 
CustomKeyword<"inout">]>,
+   Accessor<"isAnyIn", [CustomKeyword<"in">, 
CustomKeyword<"inout">]>];
+  let Subjects = SubjectList<[ParmVar]>;
+  let Documentation = [HLSLParamQualifierDocs];
+  let Args = [DefaultBoolArgument<"MergedSpelling", /*default*/0, /*fake*/1>];
+}
+
 def RandomizeLayout : InheritableAttr {
   let Spellings = [GCC<"randomize_layout">];
   let Subjects = SubjectList<[Record]>;
diff --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index fa6f6acd0c30e88..09090c94ae7fb73 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -7061,6 +7061,25 @@ The full documentation is available here: 
https://learn.microsoft.com/en-us/wind
   }];
 }
 
+def HLSLParamQualifierDocs : Documentation {
+  let Category = DocCatVariable;
+  let Content = [{
+HLSL function parameters are passed by value. Parameter declarations support
+three qualifiers to denote parameter passing behavior. The three qualifiers are
+`in`, `out` and `inout`.
+
+Parameters annotated with `in` or with no annotation are passed by value from
+the caller to the callee.
+
+Parameters annotated with `out` are written to the argument after the callee
+returns (Note: arguments values passed into `out` parameters _are not_ copied
+into the callee).
+
+Parameters annotated with `inout` are copied into the callee via a temporary,
+and copied back to the argument after the callee returns.
+  }];
+}
+
 def AnnotateTypeDocs : Documentation {
   let Category = DocCatType;
   let Heading = "annotate_type";
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 4614324babb1c91..313acc3499e3ffc 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -11989,6 +11989,7 @@ def err_hlsl_numthreads_argument_oor : Error<"argument 
'%select{X|Y|Z}0' to numt
 def err_hlsl_numthreads_invalid : Error<"total number of threads cannot exceed 
%0">;
 def err_hlsl_missing_numthreads : Error<"missing numthreads attribute for %0 
shader entry">;
 def 

[clang] [NFC] Cleanup and sort hlsl_intrinsics.h (PR #72414)

[Chris B via cfe-commits]

@@ -11,557 +11,614 @@
 
 namespace hlsl {
 
-__attribute__((availability(shadermodel, introduced = 6.0)))
-__attribute__((clang_builtin_alias(__builtin_hlsl_wave_active_count_bits))) 
uint
-WaveActiveCountBits(bool bBit);
+// Note: Functions in this file are sorted alphabetically, then grouped by base
+// element type, and the element types are sorted by size, then singed integer,
+// unsigned integer and floating point. Keeping this ordering consistent will
+// help keep this file manageable as it grows.
 
+#define _HLSL_BUILTIN_ALIAS(builtin)   
\

llvm-beanz wrote:

It being reserved is the point here. `_` macros are reserved 
for use by the compiler. This header is part of the compiler implementation. It 
ships with the compiler and is tied to it.

We could alternatively move this definition into the actual compiler code (like 
under InitPreprocessor), but that would be harder to maintain. We do similar 
things in the `__cuda_*` headers in the parent directory of this header as well 
as the target-specific intrinsic headers (see: 
https://github.com/llvm/llvm-project/blob/main/clang/lib/Headers/xmmintrin.h#L2076)

https://github.com/llvm/llvm-project/pull/72414
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [SPIRV] Add -spirv option to DXC driver (PR #65989)

[Chris B via cfe-commits]

https://github.com/llvm-beanz approved this pull request.


https://github.com/llvm/llvm-project/pull/65989
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Fix a crash when using ast-dump=json (PR #70224)

[Chris B via cfe-commits]

llvm-beanz wrote:

@elizabethandrews ignore the clang-format failure. The action isn't fetching 
enough commits from git in some cases which leads to this failure.

https://github.com/llvm/llvm-project/pull/70224
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Vector vector standard conversions (PR #71098)

[Chris B via cfe-commits]

https://github.com/llvm-beanz created 
https://github.com/llvm/llvm-project/pull/71098

HLSL supports vector truncation and element conversions as part of standard 
conversion sequences. The vector truncation conversion is a C++ second 
conversion in the conversion sequence. If a vector truncation is in a 
conversion sequence an element conversion may occur after it before the 
standard C++ third conversion.

Vector element conversions can be boolean conversions, floating point or 
integral conversions or promotions.

[HLSL Draft 
Specification](https://microsoft.github.io/hlsl-specs/specs/hlsl.pdf)

>From 73c0b9f0bdf44710a290a17c8d87bc0e3db393ef Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Wed, 1 Nov 2023 12:18:43 -0500
Subject: [PATCH] [HLSL] Vector vector standard conversions

HLSL supports vector truncation and element conversions as part of
standard conversion sequences. The vector truncation conversion is a C++
second conversion in the conversion sequence. If a vector truncation is
in a conversion sequence an element conversion may occur after it before
the standard C++ third conversion.

Vector element conversions can be boolean conversions, floating point or
integral conversions or promotions.

[HLSL Draft
Specification](https://microsoft.github.io/hlsl-specs/specs/hlsl.pdf)

../clang/test/CodeGenHLSL/BasicFeatures/standard_conversion_sequences.hl
sl
../clang/test/SemaHLSL/BuiltIns/vector-constructors-erros.hlsl
../clang/test/SemaHLSL/standard_conversion_sequences.hlsl
---
 clang/include/clang/AST/OperationKinds.def|   3 +
 .../clang/Basic/DiagnosticSemaKinds.td|   3 +
 clang/include/clang/Sema/Overload.h   |  12 +-
 clang/lib/AST/Expr.cpp|   1 +
 clang/lib/AST/ExprConstant.cpp|   2 +
 clang/lib/CodeGen/CGExpr.cpp  |   2 +
 clang/lib/CodeGen/CGExprAgg.cpp   |   2 +
 clang/lib/CodeGen/CGExprComplex.cpp   |   1 +
 clang/lib/CodeGen/CGExprConstant.cpp  |   1 +
 clang/lib/CodeGen/CGExprScalar.cpp|  23 ++-
 clang/lib/Edit/RewriteObjCFoundationAPI.cpp   |   4 +
 clang/lib/Sema/SemaChecking.cpp   |  11 +-
 clang/lib/Sema/SemaExprCXX.cpp|  83 ++
 clang/lib/Sema/SemaInit.cpp   |   2 +-
 clang/lib/Sema/SemaOverload.cpp   | 144 +-
 clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp |   3 +-
 .../standard_conversion_sequences.hlsl| 119 +++
 .../BuiltIns/vector-constructors-erros.hlsl   |   2 +-
 .../standard_conversion_sequences.hlsl|  92 +++
 19 files changed, 467 insertions(+), 43 deletions(-)
 create mode 100644 
clang/test/CodeGenHLSL/BasicFeatures/standard_conversion_sequences.hlsl
 create mode 100644 clang/test/SemaHLSL/standard_conversion_sequences.hlsl

diff --git a/clang/include/clang/AST/OperationKinds.def 
b/clang/include/clang/AST/OperationKinds.def
index 8dd98730dff7426..e497fe4d1f93ff4 100644
--- a/clang/include/clang/AST/OperationKinds.def
+++ b/clang/include/clang/AST/OperationKinds.def
@@ -361,6 +361,9 @@ CAST_OPERATION(AddressSpaceConversion)
 // Convert an integer initializer to an OpenCL sampler.
 CAST_OPERATION(IntToOCLSampler)
 
+// Truncate a vector type (HLSL only).
+CAST_OPERATION(VectorTruncation)
+
 //===- Binary Operations  
-===//
 // Operators listed in order of precedence.
 // Note that additions to this should also update the StmtVisitor class,
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 224c0df7f1fb71f..01ba3a24e0018ba 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -12005,6 +12005,9 @@ def err_hlsl_pointers_unsupported : Error<
 def err_hlsl_operator_unsupported : Error<
   "the '%select{&|*|->}0' operator is unsupported in HLSL">;
 
+def warn_hlsl_impcast_vector_truncation : Warning<
+  "implicit conversion truncates vector: %0 to %1">, InGroup;
+
 // Layout randomization diagnostics.
 def err_non_designated_init_used : Error<
   "a randomized struct can only be initialized with a designated initializer">;
diff --git a/clang/include/clang/Sema/Overload.h 
b/clang/include/clang/Sema/Overload.h
index a97968dc7b20967..0d4aaa5ff7c766b 100644
--- a/clang/include/clang/Sema/Overload.h
+++ b/clang/include/clang/Sema/Overload.h
@@ -192,6 +192,9 @@ class Sema;
 /// C-only conversion between pointers with incompatible types
 ICK_Incompatible_Pointer_Conversion,
 
+/// HLSL vector truncation.
+ICK_HLSL_Vector_Truncation,
+
 /// The number of conversion kinds
 ICK_Num_Conversion_Kinds,
   };
@@ -271,6 +274,12 @@ class Sema;
 /// pointer-to-member conversion, or boolean conversion.
 ImplicitConversionKind Second : 8;
 
+/// Element - Between the second and third conversion a vector or matrix
+/// element conversion may occur.

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

[Chris B via cfe-commits]

https://github.com/llvm-beanz created 
https://github.com/llvm/llvm-project/pull/75397

This adds a new document that covers the HLSL approach to function calls and 
parameter semantics. At time of writing this document is a proposal for the 
implementation.

>From d6f57c27a3030f242bba62077ecd84ba49d8e468 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Wed, 13 Dec 2023 16:44:09 -0600
Subject: [PATCH] [HLSL][Docs] Add documentation for HLSL functions

This adds a new document that covers the HLSL approach to function
calls and parameter semantics. At time of writing this document is a
proposal for the implementation.
---
 clang/docs/HLSL/FunctionCalls.rst | 300 ++
 clang/docs/HLSL/HLSLDocs.rst  |   1 +
 2 files changed, 301 insertions(+)
 create mode 100644 clang/docs/HLSL/FunctionCalls.rst

diff --git a/clang/docs/HLSL/FunctionCalls.rst 
b/clang/docs/HLSL/FunctionCalls.rst
new file mode 100644
index 00..aeddac087cb89d
--- /dev/null
+++ b/clang/docs/HLSL/FunctionCalls.rst
@@ -0,0 +1,300 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document descries the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification`_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call
+arguments are emitted right-to-left and destroyed left-to-right. This means 
that
+the parameter initialization and destruction occurs in the order: {``Y``,
+``X``, ``~X``, ``~Y``}. This causes the write-back of the value of ``Y`` to 
occur
+last, so the resulting value of ``V`` is ``2``. In the Itanium C++ ABI, the
+parameter ordering is reversed, so the initialization and destruction occurs in
+the order: {``X``, ``Y``, ``~Y``, ``X``}. This causes the write-back of the
+value ``X`` to occur last, resulting in the value of ``V`` being set to ``1``.
+
+.. code-block:: 

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

[Chris B via cfe-commits]

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/75397

>From 4ebc0c58dc751f422de85b0909636cb1a87f8ce4 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Wed, 13 Dec 2023 16:44:09 -0600
Subject: [PATCH] [HLSL][Docs] Add documentation for HLSL functions

This adds a new document that covers the HLSL approach to function
calls and parameter semantics. At time of writing this document is a
proposal for the implementation.
---
 clang/docs/HLSL/FunctionCalls.rst | 316 ++
 clang/docs/HLSL/HLSLDocs.rst  |   1 +
 2 files changed, 317 insertions(+)
 create mode 100644 clang/docs/HLSL/FunctionCalls.rst

diff --git a/clang/docs/HLSL/FunctionCalls.rst 
b/clang/docs/HLSL/FunctionCalls.rst
new file mode 100644
index 00..e62b249e011a94
--- /dev/null
+++ b/clang/docs/HLSL/FunctionCalls.rst
@@ -0,0 +1,316 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document descries the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification `_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call
+arguments are emitted right-to-left and destroyed left-to-right. This means 
that
+the parameter initialization and destruction occurs in the order: {``Y``,
+``X``, ``~X``, ``~Y``}. This causes the write-back of the value of ``Y`` to 
occur
+last, so the resulting value of ``V`` is ``2``. In the Itanium C++ ABI, the
+parameter ordering is reversed, so the initialization and destruction occurs in
+the order: {``X``, ``Y``, ``~Y``, ``X``}. This causes the write-back of the
+value ``X`` to occur last, resulting in the value of ``V`` being set to ``1``.
+
+.. code-block:: c++
+
+  void Trunc(inout int3 V) { }
+
+
+  void main() {
+float3 F = {1.5, 2.6, 3.3};
+Trunc(F); // F == {1.0, 2.0, 3.0}
+  }
+
+In the above example, the 

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

[Chris B via cfe-commits]

@@ -0,0 +1,300 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document descries the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification`_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call

llvm-beanz wrote:

I don't think we explicitly define it, but we need the Clang DXIL generation to 
match otherwise we could expose subtle bugs.

https://github.com/llvm/llvm-project/pull/75397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

[Chris B via cfe-commits]

@@ -0,0 +1,300 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document descries the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification`_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call
+arguments are emitted right-to-left and destroyed left-to-right. This means 
that
+the parameter initialization and destruction occurs in the order: {``Y``,
+``X``, ``~X``, ``~Y``}. This causes the write-back of the value of ``Y`` to 
occur
+last, so the resulting value of ``V`` is ``2``. In the Itanium C++ ABI, the
+parameter ordering is reversed, so the initialization and destruction occurs in
+the order: {``X``, ``Y``, ``~Y``, ``X``}. This causes the write-back of the
+value ``X`` to occur last, resulting in the value of ``V`` being set to ``1``.
+
+.. code-block:: c++
+  void Trunc(inout int3 V) { }
+
+
+  void main() {
+float3 F = {1.5, 2.6, 3.3};
+Trunc(F); // F == {1.0, 2.0, 3.0}
+  }
+
+In the above example, the argument expression ``F`` undergoes element-wise
+conversion from a float vector to an integer vector to create a temporary
+``int3``. On expiration the temporary undergoes elementwise conversion back to
+the floating point vector type ``float3``. This results in an implicit
+truncation of the vector even if the value is unused in the function.
+
+
+.. code-block:: c++
+  void UB(out int X) {}
+
+  void main() {
+int X = 7;
+UB(X); // X is undefined!
+  }
+
+In this example an initialized value is passed to an ``out`` parameter.
+Parameters marked ``out`` are not initialized by the argument expression or
+implicitly by the function. They must be explicitly initialized. In this case
+the argument is not initialized in the function so the temporary is still
+uninitialized when it is copied back to the argument expression. This is
+undefi

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

[Chris B via cfe-commits]

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/75397

>From 4ebc0c58dc751f422de85b0909636cb1a87f8ce4 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Wed, 13 Dec 2023 16:44:09 -0600
Subject: [PATCH 1/2] [HLSL][Docs] Add documentation for HLSL functions

This adds a new document that covers the HLSL approach to function
calls and parameter semantics. At time of writing this document is a
proposal for the implementation.
---
 clang/docs/HLSL/FunctionCalls.rst | 316 ++
 clang/docs/HLSL/HLSLDocs.rst  |   1 +
 2 files changed, 317 insertions(+)
 create mode 100644 clang/docs/HLSL/FunctionCalls.rst

diff --git a/clang/docs/HLSL/FunctionCalls.rst 
b/clang/docs/HLSL/FunctionCalls.rst
new file mode 100644
index 00..e62b249e011a94
--- /dev/null
+++ b/clang/docs/HLSL/FunctionCalls.rst
@@ -0,0 +1,316 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document descries the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification `_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call
+arguments are emitted right-to-left and destroyed left-to-right. This means 
that
+the parameter initialization and destruction occurs in the order: {``Y``,
+``X``, ``~X``, ``~Y``}. This causes the write-back of the value of ``Y`` to 
occur
+last, so the resulting value of ``V`` is ``2``. In the Itanium C++ ABI, the
+parameter ordering is reversed, so the initialization and destruction occurs in
+the order: {``X``, ``Y``, ``~Y``, ``X``}. This causes the write-back of the
+value ``X`` to occur last, resulting in the value of ``V`` being set to ``1``.
+
+.. code-block:: c++
+
+  void Trunc(inout int3 V) { }
+
+
+  void main() {
+float3 F = {1.5, 2.6, 3.3};
+Trunc(F); // F == {1.0, 2.0, 3.0}
+  }
+
+In the above example, 

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

[Chris B via cfe-commits]

@@ -0,0 +1,316 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document describes the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification `_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);

llvm-beanz wrote:

doh!

https://github.com/llvm/llvm-project/pull/75397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

[Chris B via cfe-commits]

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/75397

>From 4ebc0c58dc751f422de85b0909636cb1a87f8ce4 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Wed, 13 Dec 2023 16:44:09 -0600
Subject: [PATCH 1/3] [HLSL][Docs] Add documentation for HLSL functions

This adds a new document that covers the HLSL approach to function
calls and parameter semantics. At time of writing this document is a
proposal for the implementation.
---
 clang/docs/HLSL/FunctionCalls.rst | 316 ++
 clang/docs/HLSL/HLSLDocs.rst  |   1 +
 2 files changed, 317 insertions(+)
 create mode 100644 clang/docs/HLSL/FunctionCalls.rst

diff --git a/clang/docs/HLSL/FunctionCalls.rst 
b/clang/docs/HLSL/FunctionCalls.rst
new file mode 100644
index 00..e62b249e011a94
--- /dev/null
+++ b/clang/docs/HLSL/FunctionCalls.rst
@@ -0,0 +1,316 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document descries the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification `_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call
+arguments are emitted right-to-left and destroyed left-to-right. This means 
that
+the parameter initialization and destruction occurs in the order: {``Y``,
+``X``, ``~X``, ``~Y``}. This causes the write-back of the value of ``Y`` to 
occur
+last, so the resulting value of ``V`` is ``2``. In the Itanium C++ ABI, the
+parameter ordering is reversed, so the initialization and destruction occurs in
+the order: {``X``, ``Y``, ``~Y``, ``X``}. This causes the write-back of the
+value ``X`` to occur last, resulting in the value of ``V`` being set to ``1``.
+
+.. code-block:: c++
+
+  void Trunc(inout int3 V) { }
+
+
+  void main() {
+float3 F = {1.5, 2.6, 3.3};
+Trunc(F); // F == {1.0, 2.0, 3.0}
+  }
+
+In the above example, 

[llvm] [clang] [clang-tools-extra] [HLSL] Vector standard conversions (PR #71098)

[Chris B via cfe-commits]

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/71098

>From 91e8d9d9f63fe2ac481bb01549e3d69ac59d68f8 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Wed, 1 Nov 2023 12:18:43 -0500
Subject: [PATCH 1/7] [HLSL] Vector vector standard conversions

HLSL supports vector truncation and element conversions as part of
standard conversion sequences. The vector truncation conversion is a C++
second conversion in the conversion sequence. If a vector truncation is
in a conversion sequence an element conversion may occur after it before
the standard C++ third conversion.

Vector element conversions can be boolean conversions, floating point or
integral conversions or promotions.

[HLSL Draft
Specification](https://microsoft.github.io/hlsl-specs/specs/hlsl.pdf)

../clang/test/CodeGenHLSL/BasicFeatures/standard_conversion_sequences.hl
sl
../clang/test/SemaHLSL/BuiltIns/vector-constructors-erros.hlsl
../clang/test/SemaHLSL/standard_conversion_sequences.hlsl
---
 clang/include/clang/AST/OperationKinds.def|   3 +
 .../clang/Basic/DiagnosticSemaKinds.td|   3 +
 clang/include/clang/Sema/Overload.h   |  12 +-
 clang/lib/AST/Expr.cpp|   1 +
 clang/lib/AST/ExprConstant.cpp|   2 +
 clang/lib/CodeGen/CGExpr.cpp  |   2 +
 clang/lib/CodeGen/CGExprAgg.cpp   |   2 +
 clang/lib/CodeGen/CGExprComplex.cpp   |   1 +
 clang/lib/CodeGen/CGExprConstant.cpp  |   1 +
 clang/lib/CodeGen/CGExprScalar.cpp|  23 +-
 clang/lib/Edit/RewriteObjCFoundationAPI.cpp   |   4 +
 clang/lib/Sema/SemaChecking.cpp   |  11 +-
 clang/lib/Sema/SemaExprCXX.cpp|  84 ++
 clang/lib/Sema/SemaInit.cpp   |   2 +-
 clang/lib/Sema/SemaOverload.cpp   | 281 +++---
 clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp |   3 +-
 .../standard_conversion_sequences.hlsl| 119 
 .../BuiltIns/vector-constructors-erros.hlsl   |   2 +-
 .../standard_conversion_sequences.hlsl|  92 ++
 19 files changed, 536 insertions(+), 112 deletions(-)
 create mode 100644 
clang/test/CodeGenHLSL/BasicFeatures/standard_conversion_sequences.hlsl
 create mode 100644 clang/test/SemaHLSL/standard_conversion_sequences.hlsl

diff --git a/clang/include/clang/AST/OperationKinds.def 
b/clang/include/clang/AST/OperationKinds.def
index 8dd98730dff742..e497fe4d1f93ff 100644
--- a/clang/include/clang/AST/OperationKinds.def
+++ b/clang/include/clang/AST/OperationKinds.def
@@ -361,6 +361,9 @@ CAST_OPERATION(AddressSpaceConversion)
 // Convert an integer initializer to an OpenCL sampler.
 CAST_OPERATION(IntToOCLSampler)
 
+// Truncate a vector type (HLSL only).
+CAST_OPERATION(VectorTruncation)
+
 //===- Binary Operations  
-===//
 // Operators listed in order of precedence.
 // Note that additions to this should also update the StmtVisitor class,
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index d164177251e4db..6f21674d21fa54 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -12023,6 +12023,9 @@ def err_hlsl_operator_unsupported : Error<
 def err_hlsl_param_qualifier_mismatch :
   Error<"conflicting parameter qualifier %0 on parameter %1">;
 
+def warn_hlsl_impcast_vector_truncation : Warning<
+  "implicit conversion truncates vector: %0 to %1">, InGroup;
+
 // Layout randomization diagnostics.
 def err_non_designated_init_used : Error<
   "a randomized struct can only be initialized with a designated initializer">;
diff --git a/clang/include/clang/Sema/Overload.h 
b/clang/include/clang/Sema/Overload.h
index 6ccabad3af5446..2f93fee4d9806a 100644
--- a/clang/include/clang/Sema/Overload.h
+++ b/clang/include/clang/Sema/Overload.h
@@ -195,6 +195,9 @@ class Sema;
 /// Fixed point type conversions according to N1169.
 ICK_Fixed_Point_Conversion,
 
+/// HLSL vector truncation.
+ICK_HLSL_Vector_Truncation,
+
 /// The number of conversion kinds
 ICK_Num_Conversion_Kinds,
   };
@@ -271,6 +274,12 @@ class Sema;
 /// pointer-to-member conversion, or boolean conversion.
 ImplicitConversionKind Second : 8;
 
+/// Element - Between the second and third conversion a vector or matrix
+/// element conversion may occur. If this is not ICK_Identity this
+/// conversion is applied element-wise to each element in the vector or
+/// matrix.
+ImplicitConversionKind Element : 8;
+
 /// Third - The third conversion can be a qualification conversion
 /// or a function conversion.
 ImplicitConversionKind Third : 8;
@@ -357,7 +366,8 @@ class Sema;
 void setAsIdentityConversion();
 
 bool isIdentityConversion() const {
-  return Second == ICK_Identity && Third == ICK_Identity;
+  return Second == ICK_Identity && Element == ICK_Identity &&

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

[Chris B via cfe-commits]

@@ -0,0 +1,316 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document describes the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification `_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.

llvm-beanz wrote:

I agree that we should remove these from the language, but I think our current 
implementation needs to assume that they are around since... they are.

https://github.com/llvm/llvm-project/pull/75397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

[Chris B via cfe-commits]

@@ -0,0 +1,316 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document describes the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification `_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.

llvm-beanz wrote:

I filed an issue on [HLSL 
Specs](https://github.com/microsoft/hlsl-specs/issues/141) to track considering 
approaches for unsized arrays at the language level.

https://github.com/llvm/llvm-project/pull/75397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

[Chris B via cfe-commits]

@@ -0,0 +1,316 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document describes the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification `_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (if the
+parameter is not explicitly initialized inside the function an undefined value
+is stored back to the argument expression). For input and output parameters, 
the
+temporary is initialized from  the lvalue argument expression through implicit
+or explicit casting from the lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(arr[0], arr[1], arr[2], arr[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``arr[0]`` is ``3``. In HLSL, the array is passed by 
value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call
+arguments are emitted right-to-left and destroyed left-to-right. This means 
that
+the parameter initialization and destruction occurs in the order: {``Y``,
+``X``, ``~X``, ``~Y``}. This causes the write-back of the value of ``Y`` to 
occur
+last, so the resulting value of ``V`` is ``2``. In the Itanium C++ ABI, the
+parameter ordering is reversed, so the initialization and destruction occurs in
+the order: {``X``, ``Y``, ``~Y``, ``X``}. This causes the write-back of the
+value ``X`` to occur last, resulting in the value of ``V`` being set to ``1``.
+
+.. code-block:: c++
+
+  void Trunc(inout int3 V) { }
+
+
+  void main() {
+float3 F = {1.5, 2.6, 3.3};
+Trunc(F); // F == {1.0, 2.0, 3.0}
+  }
+
+In the above example, the argument expression ``F`` undergoes element-wise
+conversion from a float vector to an integer vector to create a temporary
+``int3``. On expiration the temporary undergoes elementwise conversion back to
+the floating point vector type ``float3``. This results in an implicit
+truncation of the vector even if the value is unused in the function.
+
+
+.. code-block:: c++
+
+  void UB(out int X) {}
+
+  void main() {
+int X = 7;
+UB(X); // X is undefined!
+  }
+
+In this example an initialized value is passed to an ``out`` parameter.
+Parameters marked ``out`` are not initialized by the argument expression or
+implicitly by the function. They must be explicitly initialized. In this case
+the argument is not initialized in the function so the temporary is still
+uninitialized when i

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

[Chris B via cfe-commits]

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/75397

>From 4ebc0c58dc751f422de85b0909636cb1a87f8ce4 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Wed, 13 Dec 2023 16:44:09 -0600
Subject: [PATCH 1/4] [HLSL][Docs] Add documentation for HLSL functions

This adds a new document that covers the HLSL approach to function
calls and parameter semantics. At time of writing this document is a
proposal for the implementation.
---
 clang/docs/HLSL/FunctionCalls.rst | 316 ++
 clang/docs/HLSL/HLSLDocs.rst  |   1 +
 2 files changed, 317 insertions(+)
 create mode 100644 clang/docs/HLSL/FunctionCalls.rst

diff --git a/clang/docs/HLSL/FunctionCalls.rst 
b/clang/docs/HLSL/FunctionCalls.rst
new file mode 100644
index 00..e62b249e011a94
--- /dev/null
+++ b/clang/docs/HLSL/FunctionCalls.rst
@@ -0,0 +1,316 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document descries the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification `_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call
+arguments are emitted right-to-left and destroyed left-to-right. This means 
that
+the parameter initialization and destruction occurs in the order: {``Y``,
+``X``, ``~X``, ``~Y``}. This causes the write-back of the value of ``Y`` to 
occur
+last, so the resulting value of ``V`` is ``2``. In the Itanium C++ ABI, the
+parameter ordering is reversed, so the initialization and destruction occurs in
+the order: {``X``, ``Y``, ``~Y``, ``X``}. This causes the write-back of the
+value ``X`` to occur last, resulting in the value of ``V`` being set to ``1``.
+
+.. code-block:: c++
+
+  void Trunc(inout int3 V) { }
+
+
+  void main() {
+float3 F = {1.5, 2.6, 3.3};
+Trunc(F); // F == {1.0, 2.0, 3.0}
+  }
+
+In the above example, 

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

[Chris B via cfe-commits]

llvm-beanz wrote:

@rjmccall, I'm curious if you have any thoughts on the proposed implementation 
approach here?

The TL;DR for the gnarly bit is to have AST nodes representing parameters that 
need temporary values, and for "output" parameters where there may be cast 
sequences involved the AST node will capture the cast sequences for both 
parameter initialization and writing back to the argument lvalue. Then we can 
slightly tweak the CGCall write back support to support having a cast sequence 
in the AST.

https://github.com/llvm/llvm-project/pull/75397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [clangd] Add languages as server capabilities (PR #75633)

[Chris B via cfe-commits]

https://github.com/llvm-beanz created 
https://github.com/llvm/llvm-project/pull/75633

This change adds a list of supported langauges as part of the server 
capabilities. This is related to a PR to add HLSL support to the clangd VSCode 
plugin (https://github.com/clangd/vscode-clangd/pull/392).

The review there requested advertising HLSL support as a server capability. 
Adding a general "languages" capability seemed more appropriate.

>From 9a104c0936b65de63a786759dbc0840790d9e730 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Fri, 15 Dec 2023 11:43:26 -0600
Subject: [PATCH] [clangd] Add languages as server capabilities

This change adds a list of supported langauges as part of the server
capabilities. This is related to a PR to add HLSL support to the clangd
VSCode plugin (https://github.com/clangd/vscode-clangd/pull/392).

The review there requested advertising HLSL support as a server
capability. Adding a general "languages" capability seemed more
appropriate.
---
 clang-tools-extra/clangd/ClangdLSPServer.cpp | 2 ++
 clang-tools-extra/clangd/test/initialize-params.test | 8 
 2 files changed, 10 insertions(+)

diff --git a/clang-tools-extra/clangd/ClangdLSPServer.cpp 
b/clang-tools-extra/clangd/ClangdLSPServer.cpp
index a87da252b7a7e9..4136155403fc1d 100644
--- a/clang-tools-extra/clangd/ClangdLSPServer.cpp
+++ b/clang-tools-extra/clangd/ClangdLSPServer.cpp
@@ -623,6 +623,8 @@ void ClangdLSPServer::onInitialize(const InitializeParams 
&Params,
   {"clangdInlayHintsProvider", true},
   {"inlayHintProvider", true},
   {"foldingRangeProvider", true},
+  {"languages",
+   {"c", "cpp", "cuda-cpp", "objective-c", "objective-cpp", "hlsl"}},
   };
 
   {
diff --git a/clang-tools-extra/clangd/test/initialize-params.test 
b/clang-tools-extra/clangd/test/initialize-params.test
index a1fdae9870ab6e..81f00e0f469c52 100644
--- a/clang-tools-extra/clangd/test/initialize-params.test
+++ b/clang-tools-extra/clangd/test/initialize-params.test
@@ -48,6 +48,14 @@
 # CHECK-NEXT:  "implementationProvider": true,
 # CHECK-NEXT:  "inactiveRegionsProvider": true,
 # CHECK-NEXT:  "inlayHintProvider": true,
+# CHECK-NEXT:  "languages": [
+# CHECK-NEXT:"c",
+# CHECK-NEXT:"cpp",
+# CHECK-NEXT:"cuda-cpp",
+# CHECK-NEXT:"objective-c",
+# CHECK-NEXT:"objective-cpp",
+# CHECK-NEXT:"hlsl"
+# CHECK-NEXT:  ],
 # CHECK-NEXT:  "memoryUsageProvider": true,
 # CHECK-NEXT:  "referencesProvider": true,
 # CHECK-NEXT:  "renameProvider": true,

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

[clang-tools-extra] [clangd] Add languages as server capabilities (PR #75633)

[Chris B via cfe-commits]

llvm-beanz wrote:

> 1. Since the key we're adding to the server capabilities is a non-standard 
> extension, I'm a bit uneasy about giving it a general name like 
> `"languages"`. If the LSP were to add a key with that name but a different 
> format or interpretation, we could run into trouble. Can we name it 
> `"clangdLanguages"` instead, thereby staying within our own (improvised) 
> "namespace"?

+1 This makes sense.

> 2. Given that the plan described by Sam in [this 
> comment](https://github.com/clangd/vscode-clangd/pull/392#issuecomment-1285902875)
>  is to enable vscode-clangd support for HLSL by default once clang's support 
> for HLSL is a good enough state, what do you think about the following 
> arrangement:
>* don't include `"hlsl"` in `"clangdLanguages"` yet
>* add `"hlsl"` to `"clangdLanguages"` once the "good enough" threshold is 
> reached
>* on the client side, add HLSL to the document selector if the server 
> announces support for `"hlsl"` in `"clangdLanguages"`, **or** a client-side 
> preference (which we could name "experimental", e.g. 
> `"clangd.experimentalHLSLSupport"`) is enabled?

What about a slightly different take? What if in addition to adding 
`clangdLanguages` (without HLSL) we also add `clangdExperimentalFeatures` and 
add `HLSL` there. The problem I'm trying to solve here is to avoid someone 
enabling HLSL on a language server that doesn't advertise that it has support.

That would still allow your points:

>* early adopters can set `"clangd.experimentalHLSLSupport"` with an 
> up-to-date client paired even with a clangd 17 or older server, and get the 
> corresponding level of support
>* once the implementation quality is good enough, the server can start 
> announcing the support and all clients (not just early adopters who set the 
> pref) will have it by default with newer server versions



https://github.com/llvm/llvm-project/pull/75633
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

[Chris B via cfe-commits]

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/75397

>From 4ebc0c58dc751f422de85b0909636cb1a87f8ce4 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Wed, 13 Dec 2023 16:44:09 -0600
Subject: [PATCH 1/5] [HLSL][Docs] Add documentation for HLSL functions

This adds a new document that covers the HLSL approach to function
calls and parameter semantics. At time of writing this document is a
proposal for the implementation.
---
 clang/docs/HLSL/FunctionCalls.rst | 316 ++
 clang/docs/HLSL/HLSLDocs.rst  |   1 +
 2 files changed, 317 insertions(+)
 create mode 100644 clang/docs/HLSL/FunctionCalls.rst

diff --git a/clang/docs/HLSL/FunctionCalls.rst 
b/clang/docs/HLSL/FunctionCalls.rst
new file mode 100644
index 00..e62b249e011a94
--- /dev/null
+++ b/clang/docs/HLSL/FunctionCalls.rst
@@ -0,0 +1,316 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document descries the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification `_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call
+arguments are emitted right-to-left and destroyed left-to-right. This means 
that
+the parameter initialization and destruction occurs in the order: {``Y``,
+``X``, ``~X``, ``~Y``}. This causes the write-back of the value of ``Y`` to 
occur
+last, so the resulting value of ``V`` is ``2``. In the Itanium C++ ABI, the
+parameter ordering is reversed, so the initialization and destruction occurs in
+the order: {``X``, ``Y``, ``~Y``, ``X``}. This causes the write-back of the
+value ``X`` to occur last, resulting in the value of ``V`` being set to ``1``.
+
+.. code-block:: c++
+
+  void Trunc(inout int3 V) { }
+
+
+  void main() {
+float3 F = {1.5, 2.6, 3.3};
+Trunc(F); // F == {1.0, 2.0, 3.0}
+  }
+
+In the above example, 

[llvm] [clang-tools-extra] [clang] [HLSL] Vector standard conversions (PR #71098)

[Chris B via cfe-commits]

llvm-beanz wrote:

ping @efriedma-quic & @rjmccall

https://github.com/llvm/llvm-project/pull/71098
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [llvm] [clang] [HLSL] Vector standard conversions (PR #71098)

[Chris B via cfe-commits]

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/71098

>From 91e8d9d9f63fe2ac481bb01549e3d69ac59d68f8 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Wed, 1 Nov 2023 12:18:43 -0500
Subject: [PATCH 1/7] [HLSL] Vector vector standard conversions

HLSL supports vector truncation and element conversions as part of
standard conversion sequences. The vector truncation conversion is a C++
second conversion in the conversion sequence. If a vector truncation is
in a conversion sequence an element conversion may occur after it before
the standard C++ third conversion.

Vector element conversions can be boolean conversions, floating point or
integral conversions or promotions.

[HLSL Draft
Specification](https://microsoft.github.io/hlsl-specs/specs/hlsl.pdf)

../clang/test/CodeGenHLSL/BasicFeatures/standard_conversion_sequences.hl
sl
../clang/test/SemaHLSL/BuiltIns/vector-constructors-erros.hlsl
../clang/test/SemaHLSL/standard_conversion_sequences.hlsl
---
 clang/include/clang/AST/OperationKinds.def|   3 +
 .../clang/Basic/DiagnosticSemaKinds.td|   3 +
 clang/include/clang/Sema/Overload.h   |  12 +-
 clang/lib/AST/Expr.cpp|   1 +
 clang/lib/AST/ExprConstant.cpp|   2 +
 clang/lib/CodeGen/CGExpr.cpp  |   2 +
 clang/lib/CodeGen/CGExprAgg.cpp   |   2 +
 clang/lib/CodeGen/CGExprComplex.cpp   |   1 +
 clang/lib/CodeGen/CGExprConstant.cpp  |   1 +
 clang/lib/CodeGen/CGExprScalar.cpp|  23 +-
 clang/lib/Edit/RewriteObjCFoundationAPI.cpp   |   4 +
 clang/lib/Sema/SemaChecking.cpp   |  11 +-
 clang/lib/Sema/SemaExprCXX.cpp|  84 ++
 clang/lib/Sema/SemaInit.cpp   |   2 +-
 clang/lib/Sema/SemaOverload.cpp   | 281 +++---
 clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp |   3 +-
 .../standard_conversion_sequences.hlsl| 119 
 .../BuiltIns/vector-constructors-erros.hlsl   |   2 +-
 .../standard_conversion_sequences.hlsl|  92 ++
 19 files changed, 536 insertions(+), 112 deletions(-)
 create mode 100644 
clang/test/CodeGenHLSL/BasicFeatures/standard_conversion_sequences.hlsl
 create mode 100644 clang/test/SemaHLSL/standard_conversion_sequences.hlsl

diff --git a/clang/include/clang/AST/OperationKinds.def 
b/clang/include/clang/AST/OperationKinds.def
index 8dd98730dff742..e497fe4d1f93ff 100644
--- a/clang/include/clang/AST/OperationKinds.def
+++ b/clang/include/clang/AST/OperationKinds.def
@@ -361,6 +361,9 @@ CAST_OPERATION(AddressSpaceConversion)
 // Convert an integer initializer to an OpenCL sampler.
 CAST_OPERATION(IntToOCLSampler)
 
+// Truncate a vector type (HLSL only).
+CAST_OPERATION(VectorTruncation)
+
 //===- Binary Operations  
-===//
 // Operators listed in order of precedence.
 // Note that additions to this should also update the StmtVisitor class,
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index d164177251e4db..6f21674d21fa54 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -12023,6 +12023,9 @@ def err_hlsl_operator_unsupported : Error<
 def err_hlsl_param_qualifier_mismatch :
   Error<"conflicting parameter qualifier %0 on parameter %1">;
 
+def warn_hlsl_impcast_vector_truncation : Warning<
+  "implicit conversion truncates vector: %0 to %1">, InGroup;
+
 // Layout randomization diagnostics.
 def err_non_designated_init_used : Error<
   "a randomized struct can only be initialized with a designated initializer">;
diff --git a/clang/include/clang/Sema/Overload.h 
b/clang/include/clang/Sema/Overload.h
index 6ccabad3af5446..2f93fee4d9806a 100644
--- a/clang/include/clang/Sema/Overload.h
+++ b/clang/include/clang/Sema/Overload.h
@@ -195,6 +195,9 @@ class Sema;
 /// Fixed point type conversions according to N1169.
 ICK_Fixed_Point_Conversion,
 
+/// HLSL vector truncation.
+ICK_HLSL_Vector_Truncation,
+
 /// The number of conversion kinds
 ICK_Num_Conversion_Kinds,
   };
@@ -271,6 +274,12 @@ class Sema;
 /// pointer-to-member conversion, or boolean conversion.
 ImplicitConversionKind Second : 8;
 
+/// Element - Between the second and third conversion a vector or matrix
+/// element conversion may occur. If this is not ICK_Identity this
+/// conversion is applied element-wise to each element in the vector or
+/// matrix.
+ImplicitConversionKind Element : 8;
+
 /// Third - The third conversion can be a qualification conversion
 /// or a function conversion.
 ImplicitConversionKind Third : 8;
@@ -357,7 +366,8 @@ class Sema;
 void setAsIdentityConversion();
 
 bool isIdentityConversion() const {
-  return Second == ICK_Identity && Third == ICK_Identity;
+  return Second == ICK_Identity && Element == ICK_Identity &&

[clang] [HLSL] Vector standard conversions (PR #71098)

[Chris B via cfe-commits]

llvm-beanz wrote:

@AaronBallman, gentle ping 😄 

https://github.com/llvm/llvm-project/pull/71098
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [NFC] Cleanup and sort hlsl_intrinsics.h (PR #72414)

[Chris B via cfe-commits]

https://github.com/llvm-beanz closed 
https://github.com/llvm/llvm-project/pull/72414
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Parameter modifier parsing and AST (PR #72139)

[Chris B via cfe-commits]

https://github.com/llvm-beanz closed 
https://github.com/llvm/llvm-project/pull/72139
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Support vector swizzles on scalars (PR #67700)

[Chris B via cfe-commits]

llvm-beanz wrote:

Friendly ping @AaronBallman & @cor3ntin.

https://github.com/llvm/llvm-project/pull/67700
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Support vector swizzles on scalars (PR #67700)

[Chris B via cfe-commits]

https://github.com/llvm-beanz closed 
https://github.com/llvm/llvm-project/pull/67700
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Vector standard conversions (PR #71098)

[Chris B via cfe-commits]

@@ -123,82 +123,59 @@ CompareDerivedToBaseConversions(Sema &S, SourceLocation 
Loc,
 /// GetConversionRank - Retrieve the implicit conversion rank
 /// corresponding to the given implicit conversion kind.
 ImplicitConversionRank clang::GetConversionRank(ImplicitConversionKind Kind) {
-  static const ImplicitConversionRank
-Rank[] = {
-ICR_Exact_Match,
-ICR_Exact_Match,
-ICR_Exact_Match,
-ICR_Exact_Match,
-ICR_Exact_Match,
-ICR_Exact_Match,
-ICR_Promotion,
-ICR_Promotion,
-ICR_Promotion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_OCL_Scalar_Widening,
-ICR_Complex_Real_Conversion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_Writeback_Conversion,
-ICR_Exact_Match, // NOTE(gbiv): This may not be completely right --
- // it was omitted by the patch that added
- // ICK_Zero_Event_Conversion
-ICR_Exact_Match, // NOTE(ctopper): This may not be completely right --
- // it was omitted by the patch that added
- // ICK_Zero_Queue_Conversion
-ICR_C_Conversion,
-ICR_C_Conversion_Extension
-  };
+  static const ImplicitConversionRank Rank[] = {

llvm-beanz wrote:

How do you feel about me wrapping this in `// clang-format off ... // 
clang-format on` which will both keep the automation happy and prevent this in 
the future?

https://github.com/llvm/llvm-project/pull/71098
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Vector standard conversions (PR #71098)

[Chris B via cfe-commits]

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/71098

>From 91e8d9d9f63fe2ac481bb01549e3d69ac59d68f8 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Wed, 1 Nov 2023 12:18:43 -0500
Subject: [PATCH 1/5] [HLSL] Vector vector standard conversions

HLSL supports vector truncation and element conversions as part of
standard conversion sequences. The vector truncation conversion is a C++
second conversion in the conversion sequence. If a vector truncation is
in a conversion sequence an element conversion may occur after it before
the standard C++ third conversion.

Vector element conversions can be boolean conversions, floating point or
integral conversions or promotions.

[HLSL Draft
Specification](https://microsoft.github.io/hlsl-specs/specs/hlsl.pdf)

../clang/test/CodeGenHLSL/BasicFeatures/standard_conversion_sequences.hl
sl
../clang/test/SemaHLSL/BuiltIns/vector-constructors-erros.hlsl
../clang/test/SemaHLSL/standard_conversion_sequences.hlsl
---
 clang/include/clang/AST/OperationKinds.def|   3 +
 .../clang/Basic/DiagnosticSemaKinds.td|   3 +
 clang/include/clang/Sema/Overload.h   |  12 +-
 clang/lib/AST/Expr.cpp|   1 +
 clang/lib/AST/ExprConstant.cpp|   2 +
 clang/lib/CodeGen/CGExpr.cpp  |   2 +
 clang/lib/CodeGen/CGExprAgg.cpp   |   2 +
 clang/lib/CodeGen/CGExprComplex.cpp   |   1 +
 clang/lib/CodeGen/CGExprConstant.cpp  |   1 +
 clang/lib/CodeGen/CGExprScalar.cpp|  23 +-
 clang/lib/Edit/RewriteObjCFoundationAPI.cpp   |   4 +
 clang/lib/Sema/SemaChecking.cpp   |  11 +-
 clang/lib/Sema/SemaExprCXX.cpp|  84 ++
 clang/lib/Sema/SemaInit.cpp   |   2 +-
 clang/lib/Sema/SemaOverload.cpp   | 281 +++---
 clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp |   3 +-
 .../standard_conversion_sequences.hlsl| 119 
 .../BuiltIns/vector-constructors-erros.hlsl   |   2 +-
 .../standard_conversion_sequences.hlsl|  92 ++
 19 files changed, 536 insertions(+), 112 deletions(-)
 create mode 100644 
clang/test/CodeGenHLSL/BasicFeatures/standard_conversion_sequences.hlsl
 create mode 100644 clang/test/SemaHLSL/standard_conversion_sequences.hlsl

diff --git a/clang/include/clang/AST/OperationKinds.def 
b/clang/include/clang/AST/OperationKinds.def
index 8dd98730dff7426..e497fe4d1f93ff4 100644
--- a/clang/include/clang/AST/OperationKinds.def
+++ b/clang/include/clang/AST/OperationKinds.def
@@ -361,6 +361,9 @@ CAST_OPERATION(AddressSpaceConversion)
 // Convert an integer initializer to an OpenCL sampler.
 CAST_OPERATION(IntToOCLSampler)
 
+// Truncate a vector type (HLSL only).
+CAST_OPERATION(VectorTruncation)
+
 //===- Binary Operations  
-===//
 // Operators listed in order of precedence.
 // Note that additions to this should also update the StmtVisitor class,
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index d164177251e4db7..6f21674d21fa54d 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -12023,6 +12023,9 @@ def err_hlsl_operator_unsupported : Error<
 def err_hlsl_param_qualifier_mismatch :
   Error<"conflicting parameter qualifier %0 on parameter %1">;
 
+def warn_hlsl_impcast_vector_truncation : Warning<
+  "implicit conversion truncates vector: %0 to %1">, InGroup;
+
 // Layout randomization diagnostics.
 def err_non_designated_init_used : Error<
   "a randomized struct can only be initialized with a designated initializer">;
diff --git a/clang/include/clang/Sema/Overload.h 
b/clang/include/clang/Sema/Overload.h
index 6ccabad3af54468..2f93fee4d9806ad 100644
--- a/clang/include/clang/Sema/Overload.h
+++ b/clang/include/clang/Sema/Overload.h
@@ -195,6 +195,9 @@ class Sema;
 /// Fixed point type conversions according to N1169.
 ICK_Fixed_Point_Conversion,
 
+/// HLSL vector truncation.
+ICK_HLSL_Vector_Truncation,
+
 /// The number of conversion kinds
 ICK_Num_Conversion_Kinds,
   };
@@ -271,6 +274,12 @@ class Sema;
 /// pointer-to-member conversion, or boolean conversion.
 ImplicitConversionKind Second : 8;
 
+/// Element - Between the second and third conversion a vector or matrix
+/// element conversion may occur. If this is not ICK_Identity this
+/// conversion is applied element-wise to each element in the vector or
+/// matrix.
+ImplicitConversionKind Element : 8;
+
 /// Third - The third conversion can be a qualification conversion
 /// or a function conversion.
 ImplicitConversionKind Third : 8;
@@ -357,7 +366,8 @@ class Sema;
 void setAsIdentityConversion();
 
 bool isIdentityConversion() const {
-  return Second == ICK_Identity && Third == ICK_Identity;
+  return Second == ICK_Identity && Element == ICK_Ident

[clang] [HLSL] Vector standard conversions (PR #71098)

[Chris B via cfe-commits]

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/71098

>From 91e8d9d9f63fe2ac481bb01549e3d69ac59d68f8 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Wed, 1 Nov 2023 12:18:43 -0500
Subject: [PATCH 1/6] [HLSL] Vector vector standard conversions

HLSL supports vector truncation and element conversions as part of
standard conversion sequences. The vector truncation conversion is a C++
second conversion in the conversion sequence. If a vector truncation is
in a conversion sequence an element conversion may occur after it before
the standard C++ third conversion.

Vector element conversions can be boolean conversions, floating point or
integral conversions or promotions.

[HLSL Draft
Specification](https://microsoft.github.io/hlsl-specs/specs/hlsl.pdf)

../clang/test/CodeGenHLSL/BasicFeatures/standard_conversion_sequences.hl
sl
../clang/test/SemaHLSL/BuiltIns/vector-constructors-erros.hlsl
../clang/test/SemaHLSL/standard_conversion_sequences.hlsl
---
 clang/include/clang/AST/OperationKinds.def|   3 +
 .../clang/Basic/DiagnosticSemaKinds.td|   3 +
 clang/include/clang/Sema/Overload.h   |  12 +-
 clang/lib/AST/Expr.cpp|   1 +
 clang/lib/AST/ExprConstant.cpp|   2 +
 clang/lib/CodeGen/CGExpr.cpp  |   2 +
 clang/lib/CodeGen/CGExprAgg.cpp   |   2 +
 clang/lib/CodeGen/CGExprComplex.cpp   |   1 +
 clang/lib/CodeGen/CGExprConstant.cpp  |   1 +
 clang/lib/CodeGen/CGExprScalar.cpp|  23 +-
 clang/lib/Edit/RewriteObjCFoundationAPI.cpp   |   4 +
 clang/lib/Sema/SemaChecking.cpp   |  11 +-
 clang/lib/Sema/SemaExprCXX.cpp|  84 ++
 clang/lib/Sema/SemaInit.cpp   |   2 +-
 clang/lib/Sema/SemaOverload.cpp   | 281 +++---
 clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp |   3 +-
 .../standard_conversion_sequences.hlsl| 119 
 .../BuiltIns/vector-constructors-erros.hlsl   |   2 +-
 .../standard_conversion_sequences.hlsl|  92 ++
 19 files changed, 536 insertions(+), 112 deletions(-)
 create mode 100644 
clang/test/CodeGenHLSL/BasicFeatures/standard_conversion_sequences.hlsl
 create mode 100644 clang/test/SemaHLSL/standard_conversion_sequences.hlsl

diff --git a/clang/include/clang/AST/OperationKinds.def 
b/clang/include/clang/AST/OperationKinds.def
index 8dd98730dff7426..e497fe4d1f93ff4 100644
--- a/clang/include/clang/AST/OperationKinds.def
+++ b/clang/include/clang/AST/OperationKinds.def
@@ -361,6 +361,9 @@ CAST_OPERATION(AddressSpaceConversion)
 // Convert an integer initializer to an OpenCL sampler.
 CAST_OPERATION(IntToOCLSampler)
 
+// Truncate a vector type (HLSL only).
+CAST_OPERATION(VectorTruncation)
+
 //===- Binary Operations  
-===//
 // Operators listed in order of precedence.
 // Note that additions to this should also update the StmtVisitor class,
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index d164177251e4db7..6f21674d21fa54d 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -12023,6 +12023,9 @@ def err_hlsl_operator_unsupported : Error<
 def err_hlsl_param_qualifier_mismatch :
   Error<"conflicting parameter qualifier %0 on parameter %1">;
 
+def warn_hlsl_impcast_vector_truncation : Warning<
+  "implicit conversion truncates vector: %0 to %1">, InGroup;
+
 // Layout randomization diagnostics.
 def err_non_designated_init_used : Error<
   "a randomized struct can only be initialized with a designated initializer">;
diff --git a/clang/include/clang/Sema/Overload.h 
b/clang/include/clang/Sema/Overload.h
index 6ccabad3af54468..2f93fee4d9806ad 100644
--- a/clang/include/clang/Sema/Overload.h
+++ b/clang/include/clang/Sema/Overload.h
@@ -195,6 +195,9 @@ class Sema;
 /// Fixed point type conversions according to N1169.
 ICK_Fixed_Point_Conversion,
 
+/// HLSL vector truncation.
+ICK_HLSL_Vector_Truncation,
+
 /// The number of conversion kinds
 ICK_Num_Conversion_Kinds,
   };
@@ -271,6 +274,12 @@ class Sema;
 /// pointer-to-member conversion, or boolean conversion.
 ImplicitConversionKind Second : 8;
 
+/// Element - Between the second and third conversion a vector or matrix
+/// element conversion may occur. If this is not ICK_Identity this
+/// conversion is applied element-wise to each element in the vector or
+/// matrix.
+ImplicitConversionKind Element : 8;
+
 /// Third - The third conversion can be a qualification conversion
 /// or a function conversion.
 ImplicitConversionKind Third : 8;
@@ -357,7 +366,8 @@ class Sema;
 void setAsIdentityConversion();
 
 bool isIdentityConversion() const {
-  return Second == ICK_Identity && Third == ICK_Identity;
+  return Second == ICK_Identity && Element == ICK_Ident

[clang] [HLSL] Vector standard conversions (PR #71098)

[Chris B via cfe-commits]

@@ -123,82 +123,59 @@ CompareDerivedToBaseConversions(Sema &S, SourceLocation 
Loc,
 /// GetConversionRank - Retrieve the implicit conversion rank
 /// corresponding to the given implicit conversion kind.
 ImplicitConversionRank clang::GetConversionRank(ImplicitConversionKind Kind) {
-  static const ImplicitConversionRank
-Rank[] = {
-ICR_Exact_Match,
-ICR_Exact_Match,
-ICR_Exact_Match,
-ICR_Exact_Match,
-ICR_Exact_Match,
-ICR_Exact_Match,
-ICR_Promotion,
-ICR_Promotion,
-ICR_Promotion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_OCL_Scalar_Widening,
-ICR_Complex_Real_Conversion,
-ICR_Conversion,
-ICR_Conversion,
-ICR_Writeback_Conversion,
-ICR_Exact_Match, // NOTE(gbiv): This may not be completely right --
- // it was omitted by the patch that added
- // ICK_Zero_Event_Conversion
-ICR_Exact_Match, // NOTE(ctopper): This may not be completely right --
- // it was omitted by the patch that added
- // ICK_Zero_Queue_Conversion
-ICR_C_Conversion,
-ICR_C_Conversion_Extension
-  };
+  static const ImplicitConversionRank Rank[] = {

llvm-beanz wrote:

By fixing the intending (but keeping one per line) I managed to both make 
clang-format happy and keep roughly the same formatting. Is that good with you?

https://github.com/llvm/llvm-project/pull/71098
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [lld] [llvm-driver] Fix usage of `InitLLVM` on Windows (PR #76306)

[Chris B via cfe-commits]

llvm-beanz wrote:

@aganea, this ends up being a nice way to collapse down a tiny bit of shared 
tool boilerplate. Thank you!

This LGTM, but let's make sure @MaskRay is happy too.

https://github.com/llvm/llvm-project/pull/76306
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [CMake][PGO] Use check targets to generate profdata for PGO builds (PR #77347)

[Chris B via cfe-commits]

llvm-beanz wrote:

Looping in some Apple people. I'm unsure if Apple is still using this 
infrastructure for generating PGO data. If so this change will impact them. 
When I wrote this, Apple had some additional test cases that got layered on top 
of the publicly available tests.

It might make sense to make this configurable by having a user-definable 
(advanced) variable that specifies which targets to run to generate PGO data.

cc: @ributzka, @Bigcheese

https://github.com/llvm/llvm-project/pull/77347
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [llvm] [clang] [HLSL] Vector standard conversions (PR #71098)

[Chris B via cfe-commits]

@@ -4763,6 +4763,20 @@ Sema::PerformImplicitConversion(Expr *From, QualType 
ToType,
  CK_ZeroToOCLOpaqueType,
  From->getValueKind()).get();
 break;
+  case ICK_HLSL_Vector_Truncation: {
+// Note: HLSL vectors are ExtVectors. Since this truncates a vector to a
+// smaller vector, this can only operate on arguments where the source and
+// destination types are ExtVectors.

llvm-beanz wrote:

HLSL's vector syntax produces ExtVectors. The `vector` type is basically:

```c++
template
using vector = T __attribute__((ext_vector_type(Sz)));
```

Then all the explicit types are just typedefs off that defined in 
`hlsl_basic_types.h`.

We haven't explicitly disabled non-Ext vector types in Clang, but they are 
disabled in DXC. I'm unsure one way or another whether we should explicitly 
disable them in Clang for HLSL.

https://github.com/llvm/llvm-project/pull/71098
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [llvm] [clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

[Chris B via cfe-commits]

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/75397

>From 4ebc0c58dc751f422de85b0909636cb1a87f8ce4 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Wed, 13 Dec 2023 16:44:09 -0600
Subject: [PATCH 1/5] [HLSL][Docs] Add documentation for HLSL functions

This adds a new document that covers the HLSL approach to function
calls and parameter semantics. At time of writing this document is a
proposal for the implementation.
---
 clang/docs/HLSL/FunctionCalls.rst | 316 ++
 clang/docs/HLSL/HLSLDocs.rst  |   1 +
 2 files changed, 317 insertions(+)
 create mode 100644 clang/docs/HLSL/FunctionCalls.rst

diff --git a/clang/docs/HLSL/FunctionCalls.rst 
b/clang/docs/HLSL/FunctionCalls.rst
new file mode 100644
index 00..e62b249e011a94
--- /dev/null
+++ b/clang/docs/HLSL/FunctionCalls.rst
@@ -0,0 +1,316 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document descries the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification `_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call
+arguments are emitted right-to-left and destroyed left-to-right. This means 
that
+the parameter initialization and destruction occurs in the order: {``Y``,
+``X``, ``~X``, ``~Y``}. This causes the write-back of the value of ``Y`` to 
occur
+last, so the resulting value of ``V`` is ``2``. In the Itanium C++ ABI, the
+parameter ordering is reversed, so the initialization and destruction occurs in
+the order: {``X``, ``Y``, ``~Y``, ``X``}. This causes the write-back of the
+value ``X`` to occur last, resulting in the value of ``V`` being set to ``1``.
+
+.. code-block:: c++
+
+  void Trunc(inout int3 V) { }
+
+
+  void main() {
+float3 F = {1.5, 2.6, 3.3};
+Trunc(F); // F == {1.0, 2.0, 3.0}
+  }
+
+In the above example, 

[llvm] [clang] [clang-tools-extra] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

[Chris B via cfe-commits]

https://github.com/llvm-beanz closed 
https://github.com/llvm/llvm-project/pull/75397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang] [clang-tools-extra] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

[Chris B via cfe-commits]

@@ -0,0 +1,321 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document describes the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification `_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (if the
+parameter is not explicitly initialized inside the function an undefined value
+is stored back to the argument expression). For parameters that are both input
+and output, the temporary is initialized from the lvalue argument expression
+through implicit  or explicit casting from the lvalue argument type to the
+parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(arr[0], arr[1], arr[2], arr[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``arr[0]`` is ``3``. In HLSL, the array is passed by 
value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+
+  DXC may pass unsized arrays directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC (or clang-cl) V == 2, Clang V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++
+implementation. C++ does not define the order in which parameters are
+initialized or destroyed. In MSVC and Clang's MSVC compatibility mode, 
arguments
+are emitted right-to-left and destroyed left-to-right. This means that  the
+parameter initialization and destruction occurs in the order: {``Y``, ``X``,
+``~X``, ``~Y``}. This causes the write-back of the value of ``Y`` to occur 
last,
+so the resulting value of ``V`` is ``2``. In the Itanium C++ ABI, the  
parameter
+ordering is reversed, so the initialization and destruction occurs in the 
order:
+{``X``, ``Y``, ``~Y``, ``X``}. This causes the write-back of the value ``X`` to
+occur last, resulting in the value of ``V`` being set to ``1``.
+
+.. code-block:: c++
+
+  void Trunc(inout int3 V) { }
+
+
+  void main() {
+float3 F = {1.5, 2.6, 3.3};
+Trunc(F); // F == {1.0, 2.0, 3.0}
+  }
+
+In the above example, the argument expression ``F`` undergoes element-wise
+conversion from a float vector to an integer vector to create a temporary
+``int3``. On expiration the temporary undergoes elementwise conversion back to
+the floating point vector type ``float3``. This results in an implicit
+element-wise conversion of the vector even if the value is unused in the
+function (effectively truncating the floating point values).
+
+
+.. code-block:: c++
+
+  void UB(out int X) {}
+
+  void main() {
+int X = 7;
+UB(X); // X is undefined!
+  }
+
+In this example an initialized value is passed to an ``out`` parameter.
+Parameters marked ``out`` are not initialized by the argument expression or
+implicitly by the function.

[clang] [HLSL] Implement array temporary support (PR #79382)

[Chris B via cfe-commits]

@@ -4655,6 +4655,13 @@ void CodeGenFunction::EmitCallArg(CallArgList &args, 
const Expr *E,
 return emitWritebackArg(*this, args, CRE);
   }
 
+  // If an argument is an array paramter expression being passed through. Emit
+  // the argument to a temporary and pass the temporary as the call arg.
+  if (auto AT = dyn_cast(type)) {
+args.add(EmitAnyExprToTemp(E), type);

llvm-beanz wrote:

Ah, yea, I think I need to fix this a different way.

The case where this happens is:

```c++
void fn(float x[2]);

void call(float Arr[2]) {
  fn(Arr);
}
```

In the CallExpr to fn, the argument is an lvalue DeclRefExpr to the ParmVar.

I think the right way to do this is to insert an ImplicitCastExpr for 
CK_HLSLArrayRValue or CK_LValueToRValue.

https://github.com/llvm/llvm-project/pull/79382
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [HLSL] Add -HV option translation to clang-dxc.exe (PR #83938)

[Chris B via cfe-commits]

https://github.com/llvm-beanz edited 
https://github.com/llvm/llvm-project/pull/83938
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [HLSL] Add -HV option translation to clang-dxc.exe (PR #83938)

[Chris B via cfe-commits]

https://github.com/llvm-beanz commented:

Minor suggestion about the diagnostic.

@MaskRay do you have any thoughts about a follow-up change to add a 
`DriverOptions` structure so that we could use argument marshalling for driver 
options?

https://github.com/llvm/llvm-project/pull/83938
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [HLSL] Add -HV option translation to clang-dxc.exe (PR #83938)

[Chris B via cfe-commits]

@@ -8545,6 +8545,11 @@ def dxc_entrypoint : Option<["--", "/", "-"], "E", 
KIND_JOINED_OR_SEPARATE>,
  Group,
  Visibility<[DXCOption]>,
  HelpText<"Entry point name">;
+def dxc_hlsl_version : Option<["/", "-"], "HV", KIND_JOINED_OR_SEPARATE>,
+ Group,
+ Visibility<[DXCOption]>,
+ HelpText<"HLSL Version">,
+ NormalizedValues<["2016", "2017", "2018", "2021", 
"202x"]>;

llvm-beanz wrote:

In the current state of this patch I don't think this does anything. I don't 
think the `Values` or `NormalizedValues` stuff really do anything (other than 
maybe populating the help spew) if you're not using the marshalling 
infrastructure 
(https://clang.llvm.org/docs/InternalsManual.html#option-marshalling-infrastructure).

We don't currently have a `DriverOptions` construct, so driver-only options 
can't use the marshalling stuff, which is unfortunate.

I think for the purposes of this change we should probably go with the 
direction in this PR and revisit marshalling later.

https://github.com/llvm/llvm-project/pull/83938
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [HLSL] Add -HV option translation to clang-dxc.exe (PR #83938)

[Chris B via cfe-commits]

@@ -753,6 +753,9 @@ def err_drv_hlsl_bad_shader_required_in_target : Error<
 
 def err_drv_hlsl_bad_shader_unsupported : Error<
   "%select{shader model|Vulkan environment|shader stage}0 '%1' in target '%2' 
is invalid for HLSL code generation">;
+def err_drv_hlsl_dxc_bad_argument_value : Error<

llvm-beanz wrote:

Can we use `err_drv_invalid_value` instead? I don't think there is any reason 
the error needs to say `dxc` in the text.

https://github.com/llvm/llvm-project/pull/83938
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [HLSL] Add -HV option translation to clang-dxc.exe (PR #83938)

[Chris B via cfe-commits]

@@ -8545,6 +8545,13 @@ def dxc_entrypoint : Option<["--", "/", "-"], "E", 
KIND_JOINED_OR_SEPARATE>,
  Group,
  Visibility<[DXCOption]>,
  HelpText<"Entry point name">;
+def dxc_hlsl_version : Option<["/", "-"], "HV", KIND_JOINED_OR_SEPARATE>,
+ Group,
+ Visibility<[DXCOption]>,
+ HelpText<"HLSL Version">,
+ Values<"2016, 2017, 2018, 2021, 202x">,
+ NormalizedValuesScope<"LangStandard">,
+ NormalizedValues<["hlsl2016", "hlsl2017", "hlsl2018", 
"hlsl2021", "hlsl202x"]>;

llvm-beanz wrote:

nit: Do we need these? The `-help` spew should be driven by the `Values` entry 
right?
```suggestion
```

https://github.com/llvm/llvm-project/pull/83938
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [HLSL] Add -HV option translation to clang-dxc.exe (PR #83938)

[Chris B via cfe-commits]

https://github.com/llvm-beanz approved this pull request.

Two small nits with suggestions. Otherwise LGTM.

https://github.com/llvm/llvm-project/pull/83938
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [HLSL] Add -HV option translation to clang-dxc.exe (PR #83938)

[Chris B via cfe-commits]

https://github.com/llvm-beanz edited 
https://github.com/llvm/llvm-project/pull/83938
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [HLSL] Add -HV option translation to clang-dxc.exe (PR #83938)

[Chris B via cfe-commits]

@@ -753,6 +753,7 @@ def err_drv_hlsl_bad_shader_required_in_target : Error<
 
 def err_drv_hlsl_bad_shader_unsupported : Error<
   "%select{shader model|Vulkan environment|shader stage}0 '%1' in target '%2' 
is invalid for HLSL code generation">;
+

llvm-beanz wrote:

nit: leftover whitespace change.
```suggestion
```

https://github.com/llvm/llvm-project/pull/83938
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Implement array temporary support (PR #79382)

[Chris B via cfe-commits]

@@ -3173,41 +3174,46 @@ class ArrayType : public Type, public 
llvm::FoldingSetNode {
 return T->getTypeClass() == ConstantArray ||
T->getTypeClass() == VariableArray ||
T->getTypeClass() == IncompleteArray ||
-   T->getTypeClass() == DependentSizedArray;
+   T->getTypeClass() == DependentSizedArray ||
+   T->getTypeClass() == ArrayParameter;
   }
 };
 
 /// Represents the canonical version of C arrays with a specified constant 
size.
 /// For example, the canonical type for 'int A[4 + 4*100]' is a
 /// ConstantArrayType where the element type is 'int' and the size is 404.
-class ConstantArrayType final
-: public ArrayType,
-  private llvm::TrailingObjects {

llvm-beanz wrote:

My team is trying to be pedantic about tracking our work, so I've filed #85124 
to track implementing @zygoloid's suggestion. I'll try and get a PR up for that 
in the next day or two then update this PR on top of that change.

https://github.com/llvm/llvm-project/pull/79382
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [DXIL] `exp`, `any`, `lerp`, & `rcp` Intrinsic Lowering (PR #84526)

[Chris B via cfe-commits]

https://github.com/llvm-beanz approved this pull request.


https://github.com/llvm/llvm-project/pull/84526
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [HLSL] implement `clamp` intrinsic (PR #85424)

[Chris B via cfe-commits]

https://github.com/llvm-beanz approved this pull request.


https://github.com/llvm/llvm-project/pull/85424
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [NFC] Refactor ConstantArrayType size storage (PR #85716)

[Chris B via cfe-commits]

https://github.com/llvm-beanz created 
https://github.com/llvm/llvm-project/pull/85716

In PR #79382, I need to add a new type that derives from ConstantArrayType. 
This means that ConstantArrayType can no longer use `llvm::TrailingObjects` to 
store the trailing optional Expr*.

This change refactors ConstantArrayType to store a 60-bit integer and 4-bits 
for the integer size in bytes. This replaces the APInt field previously in the 
type but preserves enough information to recreate it where needed.

To reduce the number of places where the APInt is re-constructed I've also 
added some helper methods to the ConstantArrayType to allow some common use 
cases that operate on either the stored small integer or the APInt as 
appropriate.

Resolves #85124.

>From 4a11a73b4dd41637b1d730489954c2994489d6be Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Mon, 18 Mar 2024 17:30:41 -0500
Subject: [PATCH] [NFC] Refactor ConstantArrayType size storage

In PR #79382, I need to add a new type that derives from
ConstantArrayType. This means that ConstantArrayType can no longer use
`llvm::TrailingObjects` to store the trailing optional Expr*.

This change refactors ConstantArrayType to store a 60-bit integer and
4-bits for the integer size in bytes. This replaces the APInt field
previously in the type but preserves enough information to recreate it
where needed.

To reduce the number of places where the APInt is re-constructed I've
also added some helper methods to the ConstantArrayType to allow some
common use cases that operate on either the stored small integer or the
APInt as appropriate.

Resolves #85124.
---
 clang/include/clang/AST/Type.h| 104 ++
 clang/lib/AST/ASTContext.cpp  |  21 ++--
 clang/lib/AST/Decl.cpp|   2 +-
 clang/lib/AST/ExprConstant.cpp|  30 ++---
 clang/lib/AST/Interp/ByteCodeExprGen.cpp  |   8 +-
 clang/lib/AST/Interp/EvaluationResult.cpp |   2 +-
 clang/lib/AST/Interp/Program.cpp  |   2 +-
 clang/lib/AST/JSONNodeDumper.cpp  |   2 +-
 clang/lib/AST/MicrosoftMangle.cpp |   3 +-
 clang/lib/AST/ScanfFormatString.cpp   |   2 +-
 clang/lib/AST/Type.cpp|  20 +++-
 clang/lib/AST/TypePrinter.cpp |   2 +-
 clang/lib/Analysis/CFG.cpp|   4 +-
 clang/lib/Analysis/UnsafeBufferUsage.cpp  |   8 +-
 clang/lib/CodeGen/ABIInfo.cpp |   4 +-
 clang/lib/CodeGen/ABIInfoImpl.cpp |   4 +-
 clang/lib/CodeGen/CGCall.cpp  |   4 +-
 clang/lib/CodeGen/CGDebugInfo.cpp |   2 +-
 clang/lib/CodeGen/CGExprCXX.cpp   |   6 +-
 clang/lib/CodeGen/CGExprConstant.cpp  |   8 +-
 clang/lib/CodeGen/CGObjCMac.cpp   |   6 +-
 clang/lib/CodeGen/CGOpenMPRuntime.cpp |   4 +-
 clang/lib/CodeGen/CodeGenFunction.cpp |   4 +-
 clang/lib/CodeGen/CodeGenModule.cpp   |   2 +-
 clang/lib/CodeGen/CodeGenTypes.cpp|   2 +-
 clang/lib/CodeGen/SwiftCallingConv.cpp|   2 +-
 clang/lib/CodeGen/Targets/ARM.cpp |   2 +-
 clang/lib/CodeGen/Targets/LoongArch.cpp   |   2 +-
 clang/lib/CodeGen/Targets/RISCV.cpp   |   2 +-
 clang/lib/CodeGen/Targets/X86.cpp |   4 +-
 clang/lib/Sema/SemaChecking.cpp   |   8 +-
 clang/lib/Sema/SemaDecl.cpp   |   2 +-
 clang/lib/Sema/SemaDeclCXX.cpp|   2 +-
 clang/lib/Sema/SemaExpr.cpp   |   4 +-
 clang/lib/Sema/SemaExprCXX.cpp|   2 +-
 clang/lib/Sema/SemaInit.cpp   |  20 ++--
 clang/lib/Sema/SemaOpenMP.cpp |   6 +-
 clang/lib/Sema/SemaSYCL.cpp   |   2 +-
 .../Checkers/CastSizeChecker.cpp  |   2 +-
 .../Checkers/PaddingChecker.cpp   |   2 +-
 clang/lib/StaticAnalyzer/Core/MemRegion.cpp   |   2 +-
 clang/lib/StaticAnalyzer/Core/RegionStore.cpp |   8 +-
 42 files changed, 201 insertions(+), 127 deletions(-)

diff --git a/clang/include/clang/AST/Type.h b/clang/include/clang/AST/Type.h
index 10916053cdfbf5..f8739fd54f33d1 100644
--- a/clang/include/clang/AST/Type.h
+++ b/clang/include/clang/AST/Type.h
@@ -1689,7 +1689,7 @@ class alignas(TypeAlignment) Type : public 
ExtQualsTypeCommonBase {
 
 /// Whether we have a stored size expression.
 LLVM_PREFERRED_TYPE(bool)
-unsigned HasStoredSizeExpr : 1;
+unsigned HasExternalSize : 1;
   };
 
   class BuiltinTypeBitfields {
@@ -3182,34 +3182,98 @@ class ArrayType : public Type, public 
llvm::FoldingSetNode {
 /// For example, the canonical type for 'int A[4 + 4*100]' is a
 /// ConstantArrayType where the element type is 'int' and the size is 404.
 class ConstantArrayType final
-: public ArrayType,
-  private llvm::TrailingObjects {
+: public ArrayType {
   friend class ASTContext; // ASTContext creates these.
-  friend TrailingObjects;
 
-  llvm::APInt Size

[clang] [llvm] [DXIL] implement dot intrinsic lowering for integers (PR #85662)

[Chris B via cfe-commits]

https://github.com/llvm-beanz commented:

One comment, otherwise looks good.

https://github.com/llvm/llvm-project/pull/85662
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [DXIL] implement dot intrinsic lowering for integers (PR #85662)

[Chris B via cfe-commits]

https://github.com/llvm-beanz edited 
https://github.com/llvm/llvm-project/pull/85662
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [DXIL] implement dot intrinsic lowering for integers (PR #85662)

[Chris B via cfe-commits]

@@ -5484,6 +5484,19 @@ bool CheckFloatOrHalfRepresentations(Sema *S, CallExpr 
*TheCall) {
   checkFloatorHalf);
 }
 
+bool CheckNoDoubleVectors(Sema *S, CallExpr *TheCall) {
+  auto checkDoubleVector = [](clang::QualType PassedType) -> bool {
+if (PassedType->isVectorType() && PassedType->hasFloatingRepresentation()) 
{
+  clang::QualType BaseType =
+  PassedType->getAs()->getElementType();

llvm-beanz wrote:

```suggestion
if (const auto *VecTy = dyn_cast(PassedType)) {
  clang::QualType BaseType = VecTy->getElementType();
```
nit: `hasFloatingRepresentation` does the `dyn_cast` to `VectorType` and 
inspects the element type. It's probably more streamlined for this case since 
we care about a specific element type to just do the `dyn_cast` and check 
inline.

https://github.com/llvm/llvm-project/pull/85662
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [NFC] Refactor ConstantArrayType size storage (PR #85716)

[Chris B via cfe-commits]

@@ -3182,34 +3182,98 @@ class ArrayType : public Type, public 
llvm::FoldingSetNode {
 /// For example, the canonical type for 'int A[4 + 4*100]' is a
 /// ConstantArrayType where the element type is 'int' and the size is 404.
 class ConstantArrayType final
-: public ArrayType,
-  private llvm::TrailingObjects {
+: public ArrayType {
   friend class ASTContext; // ASTContext creates these.
-  friend TrailingObjects;
 
-  llvm::APInt Size; // Allows us to unique the type.
+  struct ExternalSize {
+ExternalSize(const llvm::APInt &Sz, const Expr *SE)
+: Size(Sz), SizeExpr(SE) {}
+llvm::APInt Size; // Allows us to unique the type.
+const Expr *SizeExpr;
+  };
+  struct InlineSize {
+InlineSize(uint64_t TSz, uint64_t Sz) : ByteWidth(TSz), Size(Sz) {}
+uint64_t ByteWidth : 4;
+uint64_t Size : 60;
+  };
+  union {
+struct InlineSize I;
+ExternalSize *SizePtr;
+  };
 
-  ConstantArrayType(QualType et, QualType can, const llvm::APInt &size,
-const Expr *sz, ArraySizeModifier sm, unsigned tq)
-  : ArrayType(ConstantArray, et, can, sm, tq, sz), Size(size) {
-ConstantArrayTypeBits.HasStoredSizeExpr = sz != nullptr;
-if (ConstantArrayTypeBits.HasStoredSizeExpr) {
-  assert(!can.isNull() && "canonical constant array should not have size");
-  *getTrailingObjects() = sz;
-}
+  ConstantArrayType(QualType Et, QualType Can, uint64_t Width, uint64_t Sz,
+ArraySizeModifier SM, unsigned TQ)
+  : ArrayType(ConstantArray, Et, Can, SM, TQ, nullptr), I(Width / 8, Sz) {
+ConstantArrayTypeBits.HasExternalSize = false;
+assert(Sz < 0x0FFF && "Size must fit in 60 bits");
+assert(Width < 0xFF && "Type width must fit in 8 bits");

llvm-beanz wrote:

I guess that's poorly worded. I verify that Width is within 8, but I only store 
4 since the least significant bits are always zero.

https://github.com/llvm/llvm-project/pull/85716
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [DXIL] implement dot intrinsic lowering for integers (PR #85662)

[Chris B via cfe-commits]

https://github.com/llvm-beanz approved this pull request.


https://github.com/llvm/llvm-project/pull/85662
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL][docs] Document hlsl.h in the HLSL docs (PR #84081)

[Chris B via cfe-commits]

https://github.com/llvm-beanz closed 
https://github.com/llvm/llvm-project/pull/84081
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [clang][HLSL][SPRI-V] Add convergence intrinsics (PR #80680)

[Chris B via cfe-commits]

Nathan =?utf-8?q?Gauër?= ,
Nathan =?utf-8?q?Gauër?= ,
Nathan =?utf-8?q?Gauër?= ,
Nathan =?utf-8?q?Gauër?= ,
Nathan =?utf-8?q?Gauër?= ,
Nathan =?utf-8?q?Gauër?= 
Message-ID:
In-Reply-To: 



@@ -1295,11 +1295,13 @@ double4 trunc(double4);
 /// true, across all active lanes in the current wave.
 _HLSL_AVAILABILITY(shadermodel, 6.0)
 _HLSL_BUILTIN_ALIAS(__builtin_hlsl_wave_active_count_bits)
+__attribute__((convergent))

llvm-beanz wrote:

I'm not sure I entirely agree with @arsenm here.

>From the LLVM-IR and compiler implementation perspective it is helpful to be 
>able to expect that convergent is the default expected behavior, but from the 
>language perspective for HLSL it is preferable to imply that convergence is 
>the outlier because in the common case convergence isn't required.

I really don't want to tie the implementation of HLSL to a 4.5 year old PR that 
isn't merged.

@bogner, do you have thoughts here?

https://github.com/llvm/llvm-project/pull/80680
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Add validation for the -enable-16bit-types option (PR #85340)

[Chris B via cfe-commits]

@@ -4258,6 +4258,18 @@ bool CompilerInvocation::ParseLangArgs(LangOptions 
&Opts, ArgList &Args,
   } else {
 llvm_unreachable("expected DXIL or SPIR-V target");
   }
+  // validate that if fnative-half-type is given, that
+  // the language standard is at least hlsl2021, and that
+  // the target shader model is at least 6.2
+  if (Args.getLastArg(OPT_fnative_half_type)) {

llvm-beanz wrote:

We currently support fp16 in Vulkan 1.0, so this check should probably only 
apply to shader model targets:

https://godbolt.org/z/Wefc6179b

(@sudonatalie or @Keenuts can confirm)

https://github.com/llvm/llvm-project/pull/85340
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [CMake][HLSL] Add SPIRV to target list for build (PR #86323)

[Chris B via cfe-commits]

https://github.com/llvm-beanz created 
https://github.com/llvm/llvm-project/pull/86323

This change just enables the SPIR-V target by default in the HLSL build 
configurations. Since SPIR-V support is something we expect from the full HLSL 
compiler releases for pairity with DXC we should enable it in the default 
developer workflow.

>From 31c88b84577c2eac43aff35327dd956a03111d52 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Fri, 22 Mar 2024 13:32:30 -0500
Subject: [PATCH] [CMake][HLSL] Add SPIRV to target list for build

This change just enables the SPIR-V target by default in the HLSL build
configurations. Since SPIR-V support is something we expect from the
full HLSL compiler releases for pairity with DXC we should enable it in
the default developer workflow.
---
 clang/cmake/caches/HLSL.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/clang/cmake/caches/HLSL.cmake b/clang/cmake/caches/HLSL.cmake
index 71f81e53f6bd35..84850c86f12cd7 100644
--- a/clang/cmake/caches/HLSL.cmake
+++ b/clang/cmake/caches/HLSL.cmake
@@ -4,7 +4,7 @@ set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
 
 # Include the DirectX target for DXIL code generation, eventually we'll include
 # SPIR-V here too.
-set(LLVM_EXPERIMENTAL_TARGETS_TO_BUILD DirectX CACHE STRING "")
+set(LLVM_EXPERIMENTAL_TARGETS_TO_BUILD "DirectX;SPIRV" CACHE STRING "")
 
 # HLSL support is currently limted to clang, eventually it will expand to
 # clang-tools-extra too.

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

[clang] [HLSL] Remove double pow intrinsics (PR #86407)

[Chris B via cfe-commits]

https://github.com/llvm-beanz approved this pull request.

Nice catch! Thank you!

https://github.com/llvm/llvm-project/pull/86407
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

[Chris B via cfe-commits]

llvm-beanz wrote:

Philosophically I agree with this change, but I think some subprojects may need 
to adopt specific policies about how they handle files that are expected to be 
specific line endings. Specifically, Clang needs testing that verifies correct 
behavior on both CRLF and LF files in some cases, as does LLVM's split-file.

I did a pass a few years ago fixing a bunch of tests that had hard-specified 
file offsets in them that broke if you had CRLF line endings, and fixing how 
the correct line ending type was detected (some of the changes are 
13fa17db3a720d149bcd0783856347a4f09cf634, 
9d3437fbf3419502351d41ff9e28f06b0c3f06e8, 
ea836c880abcc74d3983fc35de407d647f0a002d, 
1c1b0027e86fab2b0877488abc1625a457ca70b3).

Should we come up with an expected filename format that we can use with 
gitattributes and rename the existing files rather than just listing each file 
that has special needs by itself?

https://github.com/llvm/llvm-project/pull/86318
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [clang][HLSL][SPRI-V] Add convergence intrinsics (PR #80680)

[Chris B via cfe-commits]

Nathan =?utf-8?q?Gauër?= ,
Nathan =?utf-8?q?Gauër?= ,
Nathan =?utf-8?q?Gauër?= ,
Nathan =?utf-8?q?Gauër?= ,
Nathan =?utf-8?q?Gauër?= ,
Nathan =?utf-8?q?Gauër?= ,
Nathan =?utf-8?q?Gauër?= 
Message-ID:
In-Reply-To: 



@@ -1295,11 +1295,13 @@ double4 trunc(double4);
 /// true, across all active lanes in the current wave.
 _HLSL_AVAILABILITY(shadermodel, 6.0)
 _HLSL_BUILTIN_ALIAS(__builtin_hlsl_wave_active_count_bits)
+__attribute__((convergent))

llvm-beanz wrote:

> Convergence requires all transitive callers to also be convergent. No real 
> code is going to do this. The existence of convergence operations means you 
> have a convergent language and must optimize to known-not-convergent

In languages like OpenCL and HLSL, this requirement is actually fine and we 
don't need it explicitly annotated. OpenCL and HLSL are effectively 
single-source kernel languages and all code gets inlined. So we can do robust 
attribute propagation.

https://github.com/llvm/llvm-project/pull/80680
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [clang][HLSL][SPRI-V] Add convergence intrinsics (PR #80680)

[Chris B via cfe-commits]

Nathan =?utf-8?q?Gau=C3=ABr?= ,
Nathan =?utf-8?q?Gau=C3=ABr?= ,
Nathan =?utf-8?q?Gau=C3=ABr?= ,
Nathan =?utf-8?q?Gau=C3=ABr?= ,
Nathan =?utf-8?q?Gau=C3=ABr?= ,
Nathan =?utf-8?q?Gau=C3=ABr?= ,
Nathan =?utf-8?q?Gau=C3=ABr?= 
Message-ID:
In-Reply-To: 



@@ -1295,11 +1295,13 @@ double4 trunc(double4);
 /// true, across all active lanes in the current wave.
 _HLSL_AVAILABILITY(shadermodel, 6.0)
 _HLSL_BUILTIN_ALIAS(__builtin_hlsl_wave_active_count_bits)
+__attribute__((convergent))

llvm-beanz wrote:

I filed an issue to track enabling `-fconvergent-functions` for HLSL (#86506).

https://github.com/llvm/llvm-project/pull/80680
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [CMake][HLSL] Add SPIRV to target list for build (PR #86323)

[Chris B via cfe-commits]

https://github.com/llvm-beanz closed 
https://github.com/llvm/llvm-project/pull/86323
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [NFC] Refactor ConstantArrayType size storage (PR #85716)

[Chris B via cfe-commits]

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/85716

>From 4a11a73b4dd41637b1d730489954c2994489d6be Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Mon, 18 Mar 2024 17:30:41 -0500
Subject: [PATCH 1/2] [NFC] Refactor ConstantArrayType size storage

In PR #79382, I need to add a new type that derives from
ConstantArrayType. This means that ConstantArrayType can no longer use
`llvm::TrailingObjects` to store the trailing optional Expr*.

This change refactors ConstantArrayType to store a 60-bit integer and
4-bits for the integer size in bytes. This replaces the APInt field
previously in the type but preserves enough information to recreate it
where needed.

To reduce the number of places where the APInt is re-constructed I've
also added some helper methods to the ConstantArrayType to allow some
common use cases that operate on either the stored small integer or the
APInt as appropriate.

Resolves #85124.
---
 clang/include/clang/AST/Type.h| 104 ++
 clang/lib/AST/ASTContext.cpp  |  21 ++--
 clang/lib/AST/Decl.cpp|   2 +-
 clang/lib/AST/ExprConstant.cpp|  30 ++---
 clang/lib/AST/Interp/ByteCodeExprGen.cpp  |   8 +-
 clang/lib/AST/Interp/EvaluationResult.cpp |   2 +-
 clang/lib/AST/Interp/Program.cpp  |   2 +-
 clang/lib/AST/JSONNodeDumper.cpp  |   2 +-
 clang/lib/AST/MicrosoftMangle.cpp |   3 +-
 clang/lib/AST/ScanfFormatString.cpp   |   2 +-
 clang/lib/AST/Type.cpp|  20 +++-
 clang/lib/AST/TypePrinter.cpp |   2 +-
 clang/lib/Analysis/CFG.cpp|   4 +-
 clang/lib/Analysis/UnsafeBufferUsage.cpp  |   8 +-
 clang/lib/CodeGen/ABIInfo.cpp |   4 +-
 clang/lib/CodeGen/ABIInfoImpl.cpp |   4 +-
 clang/lib/CodeGen/CGCall.cpp  |   4 +-
 clang/lib/CodeGen/CGDebugInfo.cpp |   2 +-
 clang/lib/CodeGen/CGExprCXX.cpp   |   6 +-
 clang/lib/CodeGen/CGExprConstant.cpp  |   8 +-
 clang/lib/CodeGen/CGObjCMac.cpp   |   6 +-
 clang/lib/CodeGen/CGOpenMPRuntime.cpp |   4 +-
 clang/lib/CodeGen/CodeGenFunction.cpp |   4 +-
 clang/lib/CodeGen/CodeGenModule.cpp   |   2 +-
 clang/lib/CodeGen/CodeGenTypes.cpp|   2 +-
 clang/lib/CodeGen/SwiftCallingConv.cpp|   2 +-
 clang/lib/CodeGen/Targets/ARM.cpp |   2 +-
 clang/lib/CodeGen/Targets/LoongArch.cpp   |   2 +-
 clang/lib/CodeGen/Targets/RISCV.cpp   |   2 +-
 clang/lib/CodeGen/Targets/X86.cpp |   4 +-
 clang/lib/Sema/SemaChecking.cpp   |   8 +-
 clang/lib/Sema/SemaDecl.cpp   |   2 +-
 clang/lib/Sema/SemaDeclCXX.cpp|   2 +-
 clang/lib/Sema/SemaExpr.cpp   |   4 +-
 clang/lib/Sema/SemaExprCXX.cpp|   2 +-
 clang/lib/Sema/SemaInit.cpp   |  20 ++--
 clang/lib/Sema/SemaOpenMP.cpp |   6 +-
 clang/lib/Sema/SemaSYCL.cpp   |   2 +-
 .../Checkers/CastSizeChecker.cpp  |   2 +-
 .../Checkers/PaddingChecker.cpp   |   2 +-
 clang/lib/StaticAnalyzer/Core/MemRegion.cpp   |   2 +-
 clang/lib/StaticAnalyzer/Core/RegionStore.cpp |   8 +-
 42 files changed, 201 insertions(+), 127 deletions(-)

diff --git a/clang/include/clang/AST/Type.h b/clang/include/clang/AST/Type.h
index 10916053cdfbf5..f8739fd54f33d1 100644
--- a/clang/include/clang/AST/Type.h
+++ b/clang/include/clang/AST/Type.h
@@ -1689,7 +1689,7 @@ class alignas(TypeAlignment) Type : public 
ExtQualsTypeCommonBase {
 
 /// Whether we have a stored size expression.
 LLVM_PREFERRED_TYPE(bool)
-unsigned HasStoredSizeExpr : 1;
+unsigned HasExternalSize : 1;
   };
 
   class BuiltinTypeBitfields {
@@ -3182,34 +3182,98 @@ class ArrayType : public Type, public 
llvm::FoldingSetNode {
 /// For example, the canonical type for 'int A[4 + 4*100]' is a
 /// ConstantArrayType where the element type is 'int' and the size is 404.
 class ConstantArrayType final
-: public ArrayType,
-  private llvm::TrailingObjects {
+: public ArrayType {
   friend class ASTContext; // ASTContext creates these.
-  friend TrailingObjects;
 
-  llvm::APInt Size; // Allows us to unique the type.
+  struct ExternalSize {
+ExternalSize(const llvm::APInt &Sz, const Expr *SE)
+: Size(Sz), SizeExpr(SE) {}
+llvm::APInt Size; // Allows us to unique the type.
+const Expr *SizeExpr;
+  };
+  struct InlineSize {
+InlineSize(uint64_t TSz, uint64_t Sz) : ByteWidth(TSz), Size(Sz) {}
+uint64_t ByteWidth : 4;
+uint64_t Size : 60;
+  };
+  union {
+struct InlineSize I;
+ExternalSize *SizePtr;
+  };
 
-  ConstantArrayType(QualType et, QualType can, const llvm::APInt &size,
-const Expr *sz, ArraySizeModifier sm, unsigned tq)
-  : ArrayType(ConstantArray, et, can, sm, tq, sz)

[clang] [HLSL] remove double impelementation of log, sin, trunc intrinsics (PR #86440)

[Chris B via cfe-commits]

https://github.com/llvm-beanz approved this pull request.


https://github.com/llvm/llvm-project/pull/86440
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [DXIL] Add Float `Dot` Intrinsic Lowering (PR #86071)

[Chris B via cfe-commits]

https://github.com/llvm-beanz approved this pull request.


https://github.com/llvm/llvm-project/pull/86071
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] prevent generation of double intrinsics via the builtins (PR #86555)

[Chris B via cfe-commits]

https://github.com/llvm-beanz approved this pull request.


https://github.com/llvm/llvm-project/pull/86555
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [HLSL][DXIL] implement `sqrt` intrinsic (PR #86560)

[Chris B via cfe-commits]

https://github.com/llvm-beanz approved this pull request.


https://github.com/llvm/llvm-project/pull/86560
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

[Chris B via cfe-commits]

llvm-beanz wrote:

> I am not saying this isn't a problem at all, but how often has anyone done a 
> one line change and caused a 50k diff, and submitted it without noticing?

Way more often than you would hope. I don't have numbers but if you search 
through the git history for `crlf` or `dos2unix` those phrases hit on a lot of 
commits (more than just my abolishcrlf.org email address).


https://github.com/llvm/llvm-project/pull/86318
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

[Chris B via cfe-commits]

llvm-beanz wrote:

> This ^ seems a bit problematic to me, though (where the contents of the repo 
> isn't representative of the bits we want - but perhaps it's schrodinger's 
> line endings & it doesn't matter if it's always checked out as crlf - though 
> if we one day converted to another source control system, would that be a 
> problem? are there some things that examine the underlying/"real" repo 
> contents?) - what would be the cost to using `eol=input` as you've done for 
> the mixed line ending case? below \=

The argument I would have in favor of an explicit value rather than `eol=input` 
is that it at least gives us a source of truth in the `.gitattributes` as to 
what type of line ending the file is supposed to have.

I don't have a strong feeling one way or another. I just want `autocrlf=true` 
to work reliably on all platforms.


https://github.com/llvm/llvm-project/pull/86318
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

[Chris B via cfe-commits]

llvm-beanz wrote:

> I'm a bit confused. Are you saying that as I've expressed it, `autocrlf=true` 
> won't work correctly? I _think_ you're saying you're in favour of this patch 
> _in principal_, but I need to fix the mixed line endings case?

Sorry for being unclear. I meant to express that I'm so strongly in favor of 
what you're accomplishing here that I don't want any of my feedback to stand in 
the way.

https://github.com/llvm/llvm-project/pull/86318
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [NFC] Refactor ConstantArrayType size storage (PR #85716)

[Chris B via cfe-commits]

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/85716

>From 4a11a73b4dd41637b1d730489954c2994489d6be Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Mon, 18 Mar 2024 17:30:41 -0500
Subject: [PATCH 1/4] [NFC] Refactor ConstantArrayType size storage

In PR #79382, I need to add a new type that derives from
ConstantArrayType. This means that ConstantArrayType can no longer use
`llvm::TrailingObjects` to store the trailing optional Expr*.

This change refactors ConstantArrayType to store a 60-bit integer and
4-bits for the integer size in bytes. This replaces the APInt field
previously in the type but preserves enough information to recreate it
where needed.

To reduce the number of places where the APInt is re-constructed I've
also added some helper methods to the ConstantArrayType to allow some
common use cases that operate on either the stored small integer or the
APInt as appropriate.

Resolves #85124.
---
 clang/include/clang/AST/Type.h| 104 ++
 clang/lib/AST/ASTContext.cpp  |  21 ++--
 clang/lib/AST/Decl.cpp|   2 +-
 clang/lib/AST/ExprConstant.cpp|  30 ++---
 clang/lib/AST/Interp/ByteCodeExprGen.cpp  |   8 +-
 clang/lib/AST/Interp/EvaluationResult.cpp |   2 +-
 clang/lib/AST/Interp/Program.cpp  |   2 +-
 clang/lib/AST/JSONNodeDumper.cpp  |   2 +-
 clang/lib/AST/MicrosoftMangle.cpp |   3 +-
 clang/lib/AST/ScanfFormatString.cpp   |   2 +-
 clang/lib/AST/Type.cpp|  20 +++-
 clang/lib/AST/TypePrinter.cpp |   2 +-
 clang/lib/Analysis/CFG.cpp|   4 +-
 clang/lib/Analysis/UnsafeBufferUsage.cpp  |   8 +-
 clang/lib/CodeGen/ABIInfo.cpp |   4 +-
 clang/lib/CodeGen/ABIInfoImpl.cpp |   4 +-
 clang/lib/CodeGen/CGCall.cpp  |   4 +-
 clang/lib/CodeGen/CGDebugInfo.cpp |   2 +-
 clang/lib/CodeGen/CGExprCXX.cpp   |   6 +-
 clang/lib/CodeGen/CGExprConstant.cpp  |   8 +-
 clang/lib/CodeGen/CGObjCMac.cpp   |   6 +-
 clang/lib/CodeGen/CGOpenMPRuntime.cpp |   4 +-
 clang/lib/CodeGen/CodeGenFunction.cpp |   4 +-
 clang/lib/CodeGen/CodeGenModule.cpp   |   2 +-
 clang/lib/CodeGen/CodeGenTypes.cpp|   2 +-
 clang/lib/CodeGen/SwiftCallingConv.cpp|   2 +-
 clang/lib/CodeGen/Targets/ARM.cpp |   2 +-
 clang/lib/CodeGen/Targets/LoongArch.cpp   |   2 +-
 clang/lib/CodeGen/Targets/RISCV.cpp   |   2 +-
 clang/lib/CodeGen/Targets/X86.cpp |   4 +-
 clang/lib/Sema/SemaChecking.cpp   |   8 +-
 clang/lib/Sema/SemaDecl.cpp   |   2 +-
 clang/lib/Sema/SemaDeclCXX.cpp|   2 +-
 clang/lib/Sema/SemaExpr.cpp   |   4 +-
 clang/lib/Sema/SemaExprCXX.cpp|   2 +-
 clang/lib/Sema/SemaInit.cpp   |  20 ++--
 clang/lib/Sema/SemaOpenMP.cpp |   6 +-
 clang/lib/Sema/SemaSYCL.cpp   |   2 +-
 .../Checkers/CastSizeChecker.cpp  |   2 +-
 .../Checkers/PaddingChecker.cpp   |   2 +-
 clang/lib/StaticAnalyzer/Core/MemRegion.cpp   |   2 +-
 clang/lib/StaticAnalyzer/Core/RegionStore.cpp |   8 +-
 42 files changed, 201 insertions(+), 127 deletions(-)

diff --git a/clang/include/clang/AST/Type.h b/clang/include/clang/AST/Type.h
index 10916053cdfbf5..f8739fd54f33d1 100644
--- a/clang/include/clang/AST/Type.h
+++ b/clang/include/clang/AST/Type.h
@@ -1689,7 +1689,7 @@ class alignas(TypeAlignment) Type : public 
ExtQualsTypeCommonBase {
 
 /// Whether we have a stored size expression.
 LLVM_PREFERRED_TYPE(bool)
-unsigned HasStoredSizeExpr : 1;
+unsigned HasExternalSize : 1;
   };
 
   class BuiltinTypeBitfields {
@@ -3182,34 +3182,98 @@ class ArrayType : public Type, public 
llvm::FoldingSetNode {
 /// For example, the canonical type for 'int A[4 + 4*100]' is a
 /// ConstantArrayType where the element type is 'int' and the size is 404.
 class ConstantArrayType final
-: public ArrayType,
-  private llvm::TrailingObjects {
+: public ArrayType {
   friend class ASTContext; // ASTContext creates these.
-  friend TrailingObjects;
 
-  llvm::APInt Size; // Allows us to unique the type.
+  struct ExternalSize {
+ExternalSize(const llvm::APInt &Sz, const Expr *SE)
+: Size(Sz), SizeExpr(SE) {}
+llvm::APInt Size; // Allows us to unique the type.
+const Expr *SizeExpr;
+  };
+  struct InlineSize {
+InlineSize(uint64_t TSz, uint64_t Sz) : ByteWidth(TSz), Size(Sz) {}
+uint64_t ByteWidth : 4;
+uint64_t Size : 60;
+  };
+  union {
+struct InlineSize I;
+ExternalSize *SizePtr;
+  };
 
-  ConstantArrayType(QualType et, QualType can, const llvm::APInt &size,
-const Expr *sz, ArraySizeModifier sm, unsigned tq)
-  : ArrayType(ConstantArray, et, can, sm, tq, sz)

[clang] [NFC] Refactor ConstantArrayType size storage (PR #85716)

[Chris B via cfe-commits]

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/85716

>From 4a11a73b4dd41637b1d730489954c2994489d6be Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Mon, 18 Mar 2024 17:30:41 -0500
Subject: [PATCH 1/5] [NFC] Refactor ConstantArrayType size storage

In PR #79382, I need to add a new type that derives from
ConstantArrayType. This means that ConstantArrayType can no longer use
`llvm::TrailingObjects` to store the trailing optional Expr*.

This change refactors ConstantArrayType to store a 60-bit integer and
4-bits for the integer size in bytes. This replaces the APInt field
previously in the type but preserves enough information to recreate it
where needed.

To reduce the number of places where the APInt is re-constructed I've
also added some helper methods to the ConstantArrayType to allow some
common use cases that operate on either the stored small integer or the
APInt as appropriate.

Resolves #85124.
---
 clang/include/clang/AST/Type.h| 104 ++
 clang/lib/AST/ASTContext.cpp  |  21 ++--
 clang/lib/AST/Decl.cpp|   2 +-
 clang/lib/AST/ExprConstant.cpp|  30 ++---
 clang/lib/AST/Interp/ByteCodeExprGen.cpp  |   8 +-
 clang/lib/AST/Interp/EvaluationResult.cpp |   2 +-
 clang/lib/AST/Interp/Program.cpp  |   2 +-
 clang/lib/AST/JSONNodeDumper.cpp  |   2 +-
 clang/lib/AST/MicrosoftMangle.cpp |   3 +-
 clang/lib/AST/ScanfFormatString.cpp   |   2 +-
 clang/lib/AST/Type.cpp|  20 +++-
 clang/lib/AST/TypePrinter.cpp |   2 +-
 clang/lib/Analysis/CFG.cpp|   4 +-
 clang/lib/Analysis/UnsafeBufferUsage.cpp  |   8 +-
 clang/lib/CodeGen/ABIInfo.cpp |   4 +-
 clang/lib/CodeGen/ABIInfoImpl.cpp |   4 +-
 clang/lib/CodeGen/CGCall.cpp  |   4 +-
 clang/lib/CodeGen/CGDebugInfo.cpp |   2 +-
 clang/lib/CodeGen/CGExprCXX.cpp   |   6 +-
 clang/lib/CodeGen/CGExprConstant.cpp  |   8 +-
 clang/lib/CodeGen/CGObjCMac.cpp   |   6 +-
 clang/lib/CodeGen/CGOpenMPRuntime.cpp |   4 +-
 clang/lib/CodeGen/CodeGenFunction.cpp |   4 +-
 clang/lib/CodeGen/CodeGenModule.cpp   |   2 +-
 clang/lib/CodeGen/CodeGenTypes.cpp|   2 +-
 clang/lib/CodeGen/SwiftCallingConv.cpp|   2 +-
 clang/lib/CodeGen/Targets/ARM.cpp |   2 +-
 clang/lib/CodeGen/Targets/LoongArch.cpp   |   2 +-
 clang/lib/CodeGen/Targets/RISCV.cpp   |   2 +-
 clang/lib/CodeGen/Targets/X86.cpp |   4 +-
 clang/lib/Sema/SemaChecking.cpp   |   8 +-
 clang/lib/Sema/SemaDecl.cpp   |   2 +-
 clang/lib/Sema/SemaDeclCXX.cpp|   2 +-
 clang/lib/Sema/SemaExpr.cpp   |   4 +-
 clang/lib/Sema/SemaExprCXX.cpp|   2 +-
 clang/lib/Sema/SemaInit.cpp   |  20 ++--
 clang/lib/Sema/SemaOpenMP.cpp |   6 +-
 clang/lib/Sema/SemaSYCL.cpp   |   2 +-
 .../Checkers/CastSizeChecker.cpp  |   2 +-
 .../Checkers/PaddingChecker.cpp   |   2 +-
 clang/lib/StaticAnalyzer/Core/MemRegion.cpp   |   2 +-
 clang/lib/StaticAnalyzer/Core/RegionStore.cpp |   8 +-
 42 files changed, 201 insertions(+), 127 deletions(-)

diff --git a/clang/include/clang/AST/Type.h b/clang/include/clang/AST/Type.h
index 10916053cdfbf5..f8739fd54f33d1 100644
--- a/clang/include/clang/AST/Type.h
+++ b/clang/include/clang/AST/Type.h
@@ -1689,7 +1689,7 @@ class alignas(TypeAlignment) Type : public 
ExtQualsTypeCommonBase {
 
 /// Whether we have a stored size expression.
 LLVM_PREFERRED_TYPE(bool)
-unsigned HasStoredSizeExpr : 1;
+unsigned HasExternalSize : 1;
   };
 
   class BuiltinTypeBitfields {
@@ -3182,34 +3182,98 @@ class ArrayType : public Type, public 
llvm::FoldingSetNode {
 /// For example, the canonical type for 'int A[4 + 4*100]' is a
 /// ConstantArrayType where the element type is 'int' and the size is 404.
 class ConstantArrayType final
-: public ArrayType,
-  private llvm::TrailingObjects {
+: public ArrayType {
   friend class ASTContext; // ASTContext creates these.
-  friend TrailingObjects;
 
-  llvm::APInt Size; // Allows us to unique the type.
+  struct ExternalSize {
+ExternalSize(const llvm::APInt &Sz, const Expr *SE)
+: Size(Sz), SizeExpr(SE) {}
+llvm::APInt Size; // Allows us to unique the type.
+const Expr *SizeExpr;
+  };
+  struct InlineSize {
+InlineSize(uint64_t TSz, uint64_t Sz) : ByteWidth(TSz), Size(Sz) {}
+uint64_t ByteWidth : 4;
+uint64_t Size : 60;
+  };
+  union {
+struct InlineSize I;
+ExternalSize *SizePtr;
+  };
 
-  ConstantArrayType(QualType et, QualType can, const llvm::APInt &size,
-const Expr *sz, ArraySizeModifier sm, unsigned tq)
-  : ArrayType(ConstantArray, et, can, sm, tq, sz)

[clang] [HLSL] Enable -fconvergent-functions by default (PR #86571)

[Chris B via cfe-commits]

llvm-beanz wrote:

Hi @aniplcc, thank you for the PR.

We do require test cases for bug fixes and new features (see the [Developer 
Policy](https://llvm.org/docs/DeveloperPolicy.html#test-cases).

Because this general feature is already tested for OpenCL, we can make a really 
simple test for this. Something like this should be fine:

```hlsl
// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.4-library -emit-llvm 
-disable-llvm-passes -o - %s | FileCheck %s

void fn() {
};

// CHECK: define void @"?fn@@YAXXZ"() local_unnamed_addr #[[Attr:[0-9]+]]
// CHECK: attributes #[[Attr]] = { {{[^}]*}}convergent{{[^}]*}} }
```

Put that into a file `clang/test/CodeGenHLSL/convergent-functions.hlsl` and 
build the `check-clang` target to verify that it works.

https://github.com/llvm/llvm-project/pull/86571
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [clang][HLSL][SPRI-V] Add convergence intrinsics (PR #80680)

[Chris B via cfe-commits]

Nathan =?utf-8?q?Gau=C3=ABr?= ,
Nathan =?utf-8?q?Gau=C3=ABr?= ,
Nathan =?utf-8?q?Gau=C3=ABr?= ,
Nathan =?utf-8?q?Gau=C3=ABr?= ,
Nathan =?utf-8?q?Gau=C3=ABr?= ,
Nathan =?utf-8?q?Gau=C3=ABr?= ,
Nathan =?utf-8?q?Gau=C3=ABr?= 
Message-ID:
In-Reply-To: 


https://github.com/llvm-beanz approved this pull request.

LGTM too.

https://github.com/llvm/llvm-project/pull/80680
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [NFC] Refactor ConstantArrayType size storage (PR #85716)

[Chris B via cfe-commits]

https://github.com/llvm-beanz closed 
https://github.com/llvm/llvm-project/pull/85716
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Add validation for the -enable-16bit-types option (PR #85340)

[Chris B via cfe-commits]

https://github.com/llvm-beanz commented:

One nit, but otherwise looks good.

https://github.com/llvm/llvm-project/pull/85340
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Add validation for the -enable-16bit-types option (PR #85340)

[Chris B via cfe-commits]

https://github.com/llvm-beanz edited 
https://github.com/llvm/llvm-project/pull/85340
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Add validation for the -enable-16bit-types option (PR #85340)

[Chris B via cfe-commits]

@@ -753,7 +753,10 @@ def err_drv_hlsl_unsupported_target : Error<
   "HLSL code generation is unsupported for target '%0'">;
 def err_drv_hlsl_bad_shader_required_in_target : Error<
   "%select{shader model|Vulkan environment|shader stage}0 is required as 
%select{OS|environment}1 in target '%2' for HLSL code generation">;
-
+def err_drv_dxc_enable_16bit_types_option_invalid: Error<
+  "'-enable-16bit-types' option only valid when target shader model [-T] is >= 
6.2 and HLSL Version [-HV] is >= hlsl2018, but shader model is '%0' and HLSL 
Version is '%1'">;
+def err_drv_cc1_hlsl_spirv_fnative_half_type_option_invalid: Error<
+  "'-fnative-half-type' option only valid when HLSL language standard version 
is >= 2018, but language standard version is '%0'">;

llvm-beanz wrote:

nit: I think you can use one diagnostic to express all cases. Something like:
```suggestion
def err_drv_hlsl_16bit_types_unsupported: Error<
  "'%0' option requires target HLSL Version >= 2018 and %select{|shader model 
>= 6.2}1, but HLSL Version is '%2'" %select{|and shader model is '%3'}1>;
```

Then you can emit it like:

```c++
Diags.Report(diag::err_drv_hlsl_16bit_types_unsupported)
<< "-whichever-flag" << T.isDXIL() ? 1 :0 /* 1 if dxil, 0 if 
spirv */
<< Std.getName() << T.getOSVersion().getAsString(); // For 
SPIRV you can optionally leave off the last parameter.
```

https://github.com/llvm/llvm-project/pull/85340
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Enable -fconvergent-functions by default (PR #86571)

[Chris B via cfe-commits]

llvm-beanz wrote:

> I was getting match errors with the RUN script. I went ahead and updated it 
> with the checks in: `clang/test/CodeGen/convergent-functions.cpp` Hope that's 
> correct/OK?
> 
> ```hlsl
> // RUN: %clang_cc1 -triple dxil-pc-shadermodel6.4-library -emit-llvm 
> -disable-llvm-passes -o - %s | FileCheck -check-prefixes=CHECK,CONVFUNC %s 
> 
> // CHECK: attributes
> // NOCONVFUNC-NOT: convergent
> // CONVFUNC-SAME: convergent
> // CHECK-SAME: }
> void fn() {
> };
> ```

With this the `NOCONVFUNC-NOT` line does nothing. Having multiple check 
prefixes here unnecessarily complicates the test. Since we're only running 
FileCheck once we really should only need the `CHECK` prefix.

> Now it just _checks_ the presence of `convergent` in attributes, as it does 
> in `convergent-functions.cpp`. Note: I also left out the `#0` in the 
> attributes to generalize it better. Is that okay?

I'd prefer a more specific match where we actually verify that the `convergent` 
attribute is applied to the function not just that the string `convergent` 
appears on the same line as the string `attributes`.

Something like this should work and insulates from the name mangling 
differences. I also added a run line to verify the SPIR-V targeting path which 
should be the same.

```hlsl
// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.4-library -emit-llvm 
-disable-llvm-passes -o - %s | FileCheck %s
// RUN: %clang_cc1 -triple spirv-linux-vulkan-library -emit-llvm 
-disable-llvm-passes -o - %s | FileCheck %s

void fn() {
};

// CHECK: define void {{.*}}fn{{.*}}()
// CHECK-SAME: #[[Attr:[0-9]+]]
// CHECK: attributes #[[Attr]] = { {{[^}]*}}convergent{{[^}]*}} }
```



https://github.com/llvm/llvm-project/pull/86571
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Enable -fconvergent-functions by default (PR #86571)

[Chris B via cfe-commits]

https://github.com/llvm-beanz approved this pull request.


https://github.com/llvm/llvm-project/pull/86571
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Doc][HLSL] Add documentation for root signature. (PR #83933)

[Chris B via cfe-commits]

@@ -0,0 +1,426 @@
+
+HLSL Root Signatures
+
+
+.. contents::
+   :local:
+
+Usage
+=
+
+In HLSL, the `root signature
+`_ 
+defines what types of resources are bound to the graphics pipeline. 
+
+A root signature can be specified in HLSL as a `string
+`_.
 
+The string contains a collection of comma-separated clauses that describe root 
+signature constituent components. 
+
+There are two mechanisms to compile an HLSL root signature. First, it is 
+possible to attach a root signature string to a particular shader via the 
+RootSignature attribute (in the following example, using the MyRS1 entry 
+point):
+
+.. code-block:: hlsl
+
+#define RS "RootFlags( ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT | " \ 
+  "DENY_VERTEX_SHADER_ROOT_ACCESS), " \ 
+  "CBV(b0, space = 1, flags = DATA_STATIC), " \ 
+  "SRV(t0), " \ 
+  "UAV(u0), " \ 
+  "DescriptorTable( CBV(b1), " \ 
+  " SRV(t1, numDescriptors = 8, " \ 
+  " flags = DESCRIPTORS_VOLATILE), " \ 
+  " UAV(u1, numDescriptors = unbounded, " \ 
+  " flags = DESCRIPTORS_VOLATILE)), " \ 
+  "DescriptorTable(Sampler(s0, space=1, numDescriptors = 4)), " \ 
+  "RootConstants(num32BitConstants=3, b10), " \ 
+  "StaticSampler(s1)," \ 
+  "StaticSampler(s2, " \ 
+  "  addressU = TEXTURE_ADDRESS_CLAMP, " \ 
+  "  filter = FILTER_MIN_MAG_MIP_LINEAR )"
+
+[RootSignature(RS)]
+float4 main(float4 coord : COORD) : SV_Target
+{
+"…"
+}
+
+The compiler will create and verify the root signature blob for the shader and 
+embed it alongside the shader byte code into the shader blob. 
+
+The other mechanism is to create a standalone root signature blob, perhaps to 
+reuse it with a large set of shaders, saving space. The name of the define 
+string is specified via the usual -E argument. For example:
+
+.. code-block:: sh
+
+  dxc.exe -T rootsig_1_1 MyRS1.hlsl -E MyRS1 -Fo MyRS1.fxo
+
+Note that the root signature string define can also be passed on the command 
+line, e.g, -D MyRS1=”…”.
+
+Root Signature Grammar
+==
+
+.. code-block:: peg
+
+RootSignature : (RootElement(,RootElement)?)?
+
+RootElement : RootFlags | RootConstants | RootCBV | RootSRV | RootUAV |
+  DescriptorTable | StaticSampler
+
+RootFlags : 'RootFlags' '(' (RootFlag(|RootFlag)?)? ')'
+
+RootFlag : 'ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT' | 
+   'DENY_VERTEX_SHADER_ROOT_ACCESS'
+
+RootConstants : 'RootConstants' '(' 'num32BitConstants' '=' NUMBER ',' 
+   bReg (',' 'space' '=' NUMBER)? 
+   (',' 'visibility' '=' SHADER_VISIBILITY)? ')'
+
+RootCBV : 'CBV' '(' bReg (',' 'space' '=' NUMBER)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+RootSRV : 'SRV' '(' tReg (',' 'space' '=' NUMBER)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+RootUAV : 'UAV' '(' uReg (',' 'space' '=' NUMBER)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+DescriptorTable : 'DescriptorTable' '(' (DTClause(|DTClause)?)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? ')'
+
+DTClause : CBV | SRV | UAV | Sampler
+
+CBV : 'CBV' '(' bReg (',' 'numDescriptors' '=' NUMBER)? 
+  (',' 'space' '=' NUMBER)? 
+  (',' 'offset' '=' DESCRIPTOR_RANGE_OFFSET)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+SRV : 'SRV' '(' tReg (',' 'numDescriptors' '=' NUMBER)? 
+(',' 'space' '=' NUMBER)? 
+  (',' 'offset' '=' DESCRIPTOR_RANGE_OFFSET)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+UAV : 'UAV' '(' uReg (',' 'numDescriptors' '=' NUMBER)? 
+  (',' 'space' '=' NUMBER)? 
+  (',' 'offset' '=' DESCRIPTOR_RANGE_OFFSET)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+Sampler : 'Sampler' '(' sReg (',' 'numDescriptors' '=' NUMBER)? 
+  (',' 'space' '=' NUMBER)? 
+  (',' 'offset' '=' DESCRIPTOR_RANGE_OFFSET)? (',' 'flags' '=' 
NUMBER)? ')'
+
+
+SHADER_VISIBILITY : 'SHADER_VISIBILITY_ALL' | 'SHADER_VISIBILITY_VERTEX' | 
+'SHADER_VISIBILITY_HULL' | 
+'SHADER_VISIBILITY_DOMAIN' | 
+'SHADER_VISIBILITY_GEOMETRY' | 
+'SHADER_VISIBILITY_PIXEL' | 
+'SHADER_VISIBILITY_AMPLIFICATION' | 
+'SHADER_VISIBILITY_MESH'
+
+DATA_FLAGS : 'DATA_STATIC_