================
@@ -0,0 +1,139 @@
+=============================
+HLSL Availability Diagnostics
+=============================
+
+.. contents::
+   :local:
+
+Introduction
+============
+
+HLSL availability diagnostics emits errors or warning when unavailable shader 
APIs are used. Unavailable shader APIs are APIs that are exposed in HLSL code 
but are not available in the target shader stage or shader model version.
+
+There are three modes of HLSL availability diagnostic:
+
+#. **Default mode** - compiler emits an error when an unavailable API is found 
in a code that is reachable from the shader entry point function or from an 
exported library function (when compiling a shader library)
+
+#. **Relaxed mode** - same as default mode except the compiler emits a 
warning. This mode is enabled by ``-Wno-error=hlsl-availability``.
+
+#. **Strict mode** - compiler emits an error when an unavailable API is found 
in parsed code regardless of whether it can be reached from the shader entry 
point or exported functions, or not. This mode is enabled by 
``-fhlsl-strict-diagnostics``.
+
+Implementation Details
+======================
+
+Environment Parameter
+---------------------
+
+In order to encode API availability based on the shader model version and 
shader model stage a new ``environment`` parameter was added to the existing 
Clang ``availability`` attribute. 
+
+The values allowed for this parameter are a subset of values allowed as the 
``llvm::Triple`` environment component. If the environment parameters is 
present, the declared availability attribute applies only to targets with the 
same platform and environment.
+
+Default and Relaxed Diagnostic Modes
+------------------------------------
+
+This mode is implemented in ``DiagnoseHLSLAvailability`` class in 
``SemaHLSL.cpp`` and it is invoked after the whole translation unit is parsed 
(from ``Sema::ActOnEndOfTranslationUnit``). The implementation iterates over 
all shader entry points and exported library functions in the translation unit 
and performs an AST traversal of each function body.
+
+When a reference to another function or member method is found 
(``DeclRefExpr`` or ``MemberExpr``) and it has a body, the AST of the 
referenced function is also scanned. This chain of AST traversals will reach 
all of the code that is reachable from the initial shader entry point or 
exported library function.
+
+Another approach would be to construct a call graph by traversing the AST and 
recording caller and callee for each ``CallExpr``. The availability diagnostics 
would then run on the call graph. Since Clang currently does not build any call 
graph during compilation, this seems like an unnecessary step. Traversing all 
function references (``DeclRefExpr`` or ``MemberExpr``) works just as well, and 
can be easily extended to support availability diagnostic of classes and other 
AST nodes.
----------------
llvm-beanz wrote:

nit: Maybe we can replace this paragraph with a simple statement in the 
paragraph above that traversing the decls avoids needing to generate a call 
graph.

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

Reply via email to