AvailabilityDiagnostics.rst and ExpectedDifferences.rst both had
multiple headers that were perceived to be the "top-level".
In AvailabilityDiagnostics.rst two headers had both over and underlines.
The second was the "Examples" section so it showed up in the top level
HLSL docs. The overline is removed here so it's clear it's a subheader.
In ExpectedDifferences.rst, the first header had no overline, so a few
headers that looked the same were included. The overline is added to the
top header to make clear that it's the main header.
This adds a new document about DXIL Resource Handling. I've attempted to
describe here how we intend to use TargetExtTypes to represent resources
in LLVM IR and the various intrinsics we'll need to lower these through
LLVM to DXIL.
For now this document is limited to the high level concepts and a few
details on buffer types, and there are a number of TODOs in the document
that we'll iterate on as we progress in the implementation.
This PR reworks HLSL's implicit conversion sequences. Initially I was
seeking to match DXC's behavior more closely, but that was leading to a
pile of special case rules to tie-break ambiguous cases that should
really be left as ambiguous. We've decided that we're going to break
compatibility with DXC here, and we may port this new behavior over to
DXC instead.
This change is a bit closer to C++'s overload resolution rules, but it
does have a bit of nuance around how dimension adjustment conversions
are ranked. Conversion sequence ranks for HLSL are:
* Exact match
* Scalar Widening (i.e. splat)
* Promotion
* Scalar Widening with Promotion
* Conversion
* Scalar Widening with Conversion
* Dimension Reduction (i.e. truncation)
* Dimension Reduction with Promotion
* Dimension Reduction with Conversion
In this implementation I've folded the disambiguation into the
conversion sequence ranks which does add some complexity as compared to
C++, however this avoids needing to add special casing in
`CompareStandardConversionSequences`. I believe the added conversion
rank values provide a simpler approach, but feedback is appreciated.
The HLSL language spec updates are in the PR here:
https://github.com/microsoft/hlsl-specs/pull/261
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
