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

Justin Bogner via cfe-commits cfe-commits at lists.llvm.org
Thu Dec 14 15:02:21 PST 2023


================
@@ -0,0 +1,319 @@
+===================
+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 <https://microsoft.github.io/hlsl-specs/specs/hlsl.pdf>`_.
+
+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:
+
+#. <no parameter annotation> - 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.
----------------
bogner wrote:

There's a little bit of ambiguity in this paragraph when you use the term "input and output", where it could be read as "parameters that are input and parameters that are output" rather than "parameters that are both input and output". I'm not sure the best way to improve this without getting overly wordy though - I suppose we could spell it "input-and-output" to be clear that it's atomic, or maybe we could use "both" and update that in the list above as well.

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


More information about the cfe-commits mailing list