This commit adds a new pass to hoist arrays from local to global scope
when the array only contains constant values. A local array will use
alloca and stores for initialization, but a global array uses a global
variable with a constant initializer.
The idea is that a global array with constant initializer will allow the
backend compilers to produce better code because it is much easier to see
that the array is fully constant.
* Move unused global tracing flags into single usage, closes#157.
Normalizes API-provided names to include at least a current-relative
directory, simplifying file lookups. There are still restrictions on
how expressive include handlers enable the virtual file system to be,
these should be documented on the project wiki.
Handle some errors in BeginSourceFile paths where include handlers may
cause early errors, before compilation execution can begin.
Removes the prior scheme for directory handles, where the same handle
would be returned for any parent directory.
Future improvements would be to expand dxc paths before calling into
dxcompiler, and/or to fully implement OS API calls from console apps.
Improve hcttest to describe build config better and not override env var.
This change modifies dxil constant folding to use the opcode class when
deciding if a dxil function can be constant folded. We now require a
DxilModule to be available when constant folding dxil functions.
To ensure that the dxil module is available we add a new pass that loads a
dxil module from metadata if it does not exist. We use the new pass in the
dxopt tests for constant folding.
* Ensure the cached Function->OpCodeClass map is updated
The original goal of this change was to use opcode class for deciding when we
can perform constant folding on a function.
We maintain a mapping from Function* to OpCodeClass inside the OP class.
We wanted to use this map in constant folding to decide if we can constant
fold a function to avoid string comparison on the function names.
However, it turns out that the DxilModule is not always available during
constant folding of dxil calls so we cannot use the map inside of OP. The
change contains a few bug fixes and improvements that came out of trying
to get opcode class working inside constant folding.
1. Use opcode class in dxil constant folding where possible.
2. Make sure the opcode cache is refreshed properly.
3. Remove 64-bit test for bfi.
4. Add equality comparison for the ShaderModel class.
When switching to use the opcode class for constant folding, we discovered
that our test for 64-bit bfi is invalid. There is no 64-bit overload for
bfi in dxil, so the test we had written was not legal dxil. This change
removes the 64-bit test for bfi constant prop.
This commit adds the ability to constant fold dxil intrinsics when
all inputs are constant. We reuse the llvm constant folding
infrastructure and add special cases for calls to dxil intrinsics.
Use the new CMake build support in VS2017 to build without having to run cmake
separately. Removes the need to download cmake separately.
By default binaries are built in:
%LOCALAPPDATA%\CMakeBuild\DirectXShaderCompiler\build\{build-flavor}
Build settings can be changed by modifying CMakeSettings.json.
Make sure we only use python3 compatible code. In the process of compatibility
fixes I found a bug in how we check for duplicate instruction classes. The fixed
code triggers an assert because we have duplicate instruction classes. I have
commented out the assert for now and we can re-enable it when we sort out what
we want to do about the duplicated classes.
This patch changes codegen for firstbithigh and firstbitlow.
For firstbitlow we do not generate a select on the return value from the
intrinsic. The previous codegen would check if the value is 0 and return -1 if
it was. However, the FirstbitLo intrinsic will return -1 when the input is 0 so
the select is not needed. So regardless of the input value we can take the
result of the intrinsic. This would match the code produced by fxc.
For firstbithi we check the value returned from the intrinsic for -1. If
the value returned is -1 we return -1. We do this for both signed and
unsigned intrinsics. The old codegen would check the input value for
0 and so would produce wrong code when the input value was -1.
We also disable constant folding in the front end for these intrinsics.
There was a bug in the constant folding that would cause a crash and
we are adding constant folding for dxil intrinsics to the optimizer
so we should not need it explicitly in the frontend for these
intrinsics.
* Lower resource to createHandle at clang code gen.
1. A HL createHandle will have 1 or 2 parameters.
For uav/srv/sampler, 1 parameter. 1 is the resource load from resource ptr.
For cbuffer, 2 parameter. 1 is the same. 2 is for dynamic indexing on array of cbuffers.
uav/srv/sampler don't have 2 is because all the use of them is on builtin methods. Resource on methods is scalar.
createHandle function will have metadata to save the resource information like class/kind/type/...
2. Added 2 more passes DxilLegalizeResourceUsePass DxilLegalizeStaticResourceUsePass to remove load/store on local/static resource.
Also make sure HL createHandle don't have phi operand.
3. For DxilGenerationPass, Dxil createHandle will be generated after GenerateDxilOperations.
And HLObjectOperationLowerHelper now get RK/RC from MetadataAsValue argument of HL createHandle.
* Add support for reflection on types of constant-buffer members.
This change performs a best-effort translation from the LLVM types and their DXIL annotations over to the representation exported by the current `ID3D12ShaderReflectionType` interface.
- Added missing implementation of `CShaderReflectionType` members that implement `ID3D12ShaderReflectionType`
- Added a new `CShaderReflectionType::Initialize()` that intializates the instance data from an `llvm::Type*` and its `DxilFieldAnnotation`
- The main complexity here is a helper routine to extract the appropriate `D3D_SHADER_VARIABLE_TYPE` from an `llvm::StructType*`. The current code copies the logic used in `HLModule::IsHLSLObjectType()`; that bit of copy-paste programming may need to be refactored away.
- Call into the new logic where there had been a `TODO: create reflection type` comment before
- Know issues:
- Leaks the `CShaderReflectionType` instances. It is probably best to just store the type of a variable directly in the `CShaderReflectionVariable`, but the existing declarations had an unowned pointer, so I expect a tiny bit of discussion is warranted about the right way to proceed.
- Related: I did not implement the type equality test (`ID3D12ShaderReflectionType::IsEqual()`), because I don't expect it is needed by most users, and it adds complexity. A trivial implementation might store and then compare the underlying `llvm::Type` pointers, but it isn't clear to me whether the type-equality test here is supposed to consider additional properites like offsets for `struct` fields.
Fixes issue #134
* Address small-scope review feedback.
Thanks to @marcelolr for the comments. This change tries to address the simpler style/convention issues. The memory ownership fix will come next.
* Update DXBC reflection comparison tests to comapre type reflection data.
This is a small change. I added a `CompareType()` method to `DxilContainerTest` that can compare the fields of two `ID3D12ShaderReflectionType*`, and then invoked aht routine when comparing the members of reflection contstant buffers.
The comparison applies to all the simple data fields, but does *not* test:
- Anything related to inheritance, interfaces, sub-types, etc.
- Type equality tests (they aren't being implemented right now, and I don't know if most clients of the reflection API care about them)
* Fix computation of names for fxc-compatible reflection types.
Previously I'd used the name from the DXIL *field* annotation, which obviously isn't correct.
For now I just compute type names in a relatively ad hoc fashion, using the information I glean as I destructure the type.
I also don't try to be efficient, and just use `std::string` operations to concatenate on suffixes for matrices/vectors.
Not yet handled here:
- Arrays (do they get suffixed in DXBC reflection data?)
- Object types
- Any demangling required for user-defined `struct` types (is there any?)
* More fixes to fxc-compatible reflection for types.
- A matrix may show up as an LLVM array type, so we need to be careful when unwrapping outer array types to *not* count a matrix as an array.
- Be a little more overt about handling array layouts: include a note that the `Undefined` layout is being treated as column-major (the default).
- Correct name for `uint` type in reflection (apparently it reflects as `dword`)
- Remove any `struct.` prefix from user-define `struct` type names
- Apparently `struct` types are "scalar enough" that they get `Rows` and `Columns` set to 1. Need to double-check whether this should just apply to *all* non-matrix/vector types.
- Store field types with an indirection, so that type name (stored in a `std::string`) doesn't get copied/moved and thus invalidate the pointer we store in `m_Desc.Name`
- Special-case `void` so that it can have a correct name (not sure if this will matter in practice)
* Create fxc-compatible reflection types for `StructuredBuffer` element type
- This was another case where a shader reflection type was just being left `NULL`; it just didn't have a handy `TODO` comment calling it out. :)
* More fixes for fxc-compatible type reflection.
- Reflect scalar `uint` type name as `"dword"`, but not for vector/matrix (e.g., still use `"uint3"`)
- Supress checking of the `Offset` field in type reflection for element type of a structured buffer
- Note: looking at the existing compiler output for structured buffers, there seems to be an existing (hopefully known) issue that the field offsets for `StructuredBuffer` elements don't match fxc
- Strip of prefixes from user-defined `struct` type names: `"struct."` and `"dx.alignment.legacy."`
- Try to emulate fxc behavior for computing the `Columns` field for reflection on a `struct` type
- The behavior here doesn't seem to be documented on MSDN (it implies that `Columns` would be zero for a `struct` type)
- From what I can tell, the desired value is something like "total number of scalar values (not counting objects) recursively contained in this `struct` type"
With these changes, the revamped `DxilContainerTest::ReflectionMatchesDXBC_`{`Checkin`,`Full`} tests pass.
* Implement memory management for fxc-compatible reflection types.
In previous changes the `CShaderReflectionType` instances were allowed to leak.
This change still heap allocates the types, but places `std::unique_ptr`s to them all into a field in the base shader reflection object.
The reason for storing the types together in one master list (rather than having, e.g., a `CShaderReflectionVariable` directly store a `unique_ptr` to its type) is to allow for the possibility of re-using identical types in cases where that is possible (e.g., two `cbuffer` fields that use the same `struct` type should be able to share the `CShaderReflectionType` instances for their nested fields).
* Traverse call graph to report recursive calls in the front-end.
* Emit function declarations only as needed.
* Fix extra echo output in hctbuild help.
* Remove unused test case.
* Add support to dndxc for debug line lookup, restore CFG printer passes.
* Add support to dndxc to interactively grow and shrink code font.
* Fix highlights for modified controls, and enlarge/shrink font generally.
* Remove clang header generation from the build
These headers aren't used by the compiler nor by HLSL program.
* Remove references to clang-headers and redundant discard test.
* Fix a few leaks to make tests pass with AppVerifier.
* Save imm initializer when possible.
* Remove UpdateHLSLIncompleteArrayType which already done in SemaInit.
* Take care parent record in AddMissingCastOpsInInitList and HLSLExternalSource::GetNumBasicElements.
* Support nest init list in CaculateInitListArraySizeForHLSL.
This change is to syntactically check function declarations inside a function parameter.
Note that in vanilla clang they allow this to pass in a function to a function (c99, 6.9.1). So this check should be changed once we support function pointers in HLSL.
Implement default global varaibles.
According to HLSL documentation, the global variables are set to default const unless it is specified with 'static' specifier. The front end therefore should assign 'const' specifiers for all global variables that will be in global constant buffers. We also show warnings for 'extern const' variables that have initializers since these variables should be imported from external sources.
Check Syntax errors for matrix/vector subscript operators
- Throw errors for subscript operators with index out of bounds
- Throw errors for cases where matrix/vectors are modified using subscript operators
- There was an issue on the release build with the vector/matrix variables
picking invalid candidate for overloaded array subscript operators. This was because
implicit conversion sequence was not initialized correctly.
David Peixotto
Marcelo Lopez Ruiz
Lei Zhang
Xiang Li
Tex Riddell
Tim Foley
Young Kim