[Docs] [HLSL] Documenting HLSL Entry Functions

[beanz]

Summary

This document describes the basic usage and implementation details for
HLSL entry functions in Clang.

[python3kgae]

clang/docs/HLSL/EntryFunctions.rst

11

In HLSL,

43

Maybe an example to help to understand?

45

Maybe just say this wrapper call will be inlined in case we don't inline everything in the future?

[beanz]

Updating based on feedback.

clang/docs/HLSL/EntryFunctions.rst

+====================
+HLSL Entry Functions
+====================
+
+.. contents::
+   :local:
+
+Usage
+=====
+
+In HLSL entry functions denote the starting point for shader execution. They
+must be known at compile time. For all non-library shaders, the compiler assumes
+the default entry function name ``main``, unless the DXC ``/E`` option is
+provided to specify an alternate entry point. For library shaders entry points
+are denoted using the ``[shader(...)]`` attribute.
+
+All scalar parameters to entry functions must have semantic annotations, and all
+struct parameters must have semantic annotations on every field in the struct
+declaration. Additionally if the entry function has a return type, a semantic
+annotation must be provided for the return type as well.
+
+HLSL entry functions can be called from other parts of the shader, which has
+implications on code generation.
+
+Implementation Details
+======================
+
+In clang the DXC ``/E`` option is translated to the cc1 flag ``-hlsl-entry``,
+which in turn applies the ``HLSLShader`` attribute to the function with the
+specified name. This allows code generation for entry functions to always key
+off the presence of the ``HLSLShader`` attribute, regardless of what shader
+profile you are compiling.
+
+In code generation, two functions are generated. One is the user defined
+function, which is code generated as a mangled C++ function with internal
+linkage following normal function code generation.
+
+The actual exported entry function which can be called by the GPU driver is a
+``void(void)`` function that isn't name mangled. In code generation we generate
+the unmangled entry function, instantiations of the parameters with their
+semantic values populated, and a call to the user-defined function. After the
+call instruction the return value (if any) is saved via the appropriate
+intrinsic for its semantic annotation.
+
+During optimization all calls in HLSL are inlined, so this has no impact on
+final code.

clang/docs/HLSL/HLSLDocs.rst

 .. title:: Clang HLSL Documentation
 
 .. toctree::
    :maxdepth: 1
 
    HLSLSupport
 
 HLSL Design and Implementation
 ==============================
 
 .. toctree::
    :maxdepth: 1
 
    ResourceTypes
+   EntryFunctions