HLSL constant sized array function parameters do not decay to pointers.
Instead constant sized array types are preserved as unique types for
overload resolution, template instantiation and name mangling.
This implements the change by adding a new `ArrayParameterType` which
represents a non-decaying `ConstantArrayType`. The new type behaves the
same as `ConstantArrayType` except that it does not decay to a pointer.
Values of `ConstantArrayType` in HLSL decay during overload resolution
via a new `HLSLArrayRValue` cast to `ArrayParameterType`.
`ArrayParamterType` values are passed indirectly by-value to functions
in IR generation resulting in callee generated memcpy instructions.
The behavior of HLSL function calls is documented in the [draft language
specification](https://microsoft.github.io/hlsl-specs/specs/hlsl.pdf)
under the Expr.Post.Call heading.
Additionally the design of this implementation approach is documented in
[Clang's
documentation](https://clang.llvm.org/docs/HLSL/FunctionCalls.html)
Resolves#70123
This document covers expected differences between Clang and the HLSL
reference compiler implementations (FXC & DXC). The document is not
intended to be exhaustive, but it should be a best effort to cover known
cases.
This document should document both the behavioral difference and the
explanation of why Clang differs.
The initail document covers known overload resolution differences.
---------
Co-authored-by: S. Bharadwaj Yadavalli <Bharadwaj.Yadavalli@microsoft.com>
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.
PCH supported for HLSL is added when compile in -cc1 mode using -include-pch for test AST.
This change add some notes about the support of PCH for HLSL.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D134330
HLSL uses a variety of named IR metadata and attributes to convey
additional information from the frontend to the backend. This document
tries to capture and document the named annotations to provide a
reference for future contributors.
Reviewed By: python3kgae
Differential Revision: https://reviews.llvm.org/D134304
HLSL doesn't have a C++ runtime that supports `atexit` registration. To
enable global destructors we instead rely on the `llvm.global_dtor`
mechanism.
This change disables `atexit` generation for HLSL and updates the HLSL
code generation to call global destructors on the exit from entry
functions.
Depends on D132977.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D133518
HLSL doesn't have a runtime loader model that supports global
construction by a loader or runtime initializer. To allow us to leverage
global constructors with minimal code generation impact we put calls to
the global constructors inside the generated entry function.
Differential Revision: https://reviews.llvm.org/D132977
This document describes the basic usage and implementation details for
HLSL entry functions in Clang.
Reviewed By: python3kgae
Differential Revision: https://reviews.llvm.org/D132672
Along with the new documentation this also re-organizes the HLSL docs
to a subdirectory. The hope is to continue to expand this documentation
as the HLSL implementation advances.
Differential Revision: https://reviews.llvm.org/D130794
