-
Notifications
You must be signed in to change notification settings - Fork 722
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Report error for unsupported types of SV semantics #3043
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have some suggestions for alternate ways to do things, but you're free to take them or leave them.
tools/clang/lib/Sema/SemaHLSL.cpp
Outdated
|
||
if (isTypeDef || isLocalVar) { | ||
self->Diag(semanticDecl->Loc, diag::err_hlsl_varmodifierna) | ||
<< "semantic" << declarationType; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is pre-existing of course, but I'm not sure it's consistent with our documentation as I read it here:
https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-variable-syntax#Semantic
which says that "The compiler ignores semantics unless they are declared on a global variable, or a parameter passed into a shader."
// RUN: %dxc -E main -T cs_6_0 -DTID_TY=uint3 -DGI_TY=uint -DGID_TY=uint3 -DGTID_TY=float1x1 %s | FileCheck %s -check-prefix=CHK_GTID_TY_ERR | ||
// RUN: %dxc -E main -T cs_6_0 -DTID_TY=uint3 -DGI_TY=uint -DGID_TY=uint3 -DGTID_TY=float %s | FileCheck %s -check-prefix=CHK_GTID_TY_ERR | ||
// RUN: %dxc -E main -T cs_6_0 -DTID_TY=uint3 -DGI_TY=uint -DGID_TY=uint3 -DGTID_TY=bool %s | FileCheck %s -check-prefix=CHK_GTID_TY_ERR | ||
// RUN: %dxc -E main -T cs_6_0 -DTID_TY=uint3 -DGI_TY=uint -DGID_TY=uint3 -DGTID_TY=min16float %s | FileCheck %s -check-prefix=CHK_GTID_TY_ERR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very thorough! 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, I like this approach better. Most of my comments are pretty trivial, but I'm worried about the lack of matrix handling in GetCompSize
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm afraid the location the error checking is hooked in to is still too early to pick up the majority of errors it is meant to catch. It needs to be moved to HLSignatureLower, when the signature elements are actually known. Unfortunately, that also means you won't have any of the front-end decl or semantic location information available, unless we add something to preserve it through extra debug info. The current error checking there points to the function, which should be sufficient for now.
There are other issues with the error checking that need addressing, such as disallowing matrix or array types except for very special cases, which may actually be made easier by moving to HLSignatureLower, where you can validate sizes based on the final shape (rows/columns), and basic llvm types, rather than the whole variety of decl possibilities at the high level.
If we wanted to add source locations for error handling such as this (future work), I suggest we add something to the type annotations. Normally we would try to use debug info, but for basic validation like this it is nice to be able to provide locations without requiring /Zi, and currently /Zi doesn't even provide anything better than the entry point location without additional work to preserve more.
tools/clang/lib/CodeGen/CGHLSLMS.cpp
Outdated
if (qty->isArrayType()) | ||
return GetCompSize(GetArrayElementType(qty)); | ||
if (IsHLSLMatType(qty)) | ||
return GetCompSize(GetHLSLMatElementType(qty)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should support array or matrix for system values - other than under the Other
designation for special cases.
No system value can be an array except for special cases handled under Other
.
If fxc suports matrix types, I think that's an oversight, and should not be by-design. If the matrix had multiple rows, that would be illegal for all system values except tessfactors.
tools/clang/test/HLSLFileCheck/hlsl/diagnostics/errors/unsupported_type_cs_input_semantic.hlsl
Outdated
Show resolved
Hide resolved
❌ Build DirectXShaderCompiler 1.0.4262 failed (commit 757ce14c1f by @vcsharma) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks really good!
This was a pretty big hole in error reporting and I think this will resolve it definitively.
I just have a couple concerns on specific interpretation and error propagating where I might well be confused
// Generate error and exit if semantic type | ||
// is not one of the allowed types | ||
if (!ValidateSemanticType(Entry)) | ||
return; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This provides no indication of failure to the subsequent passes, I worry this will bail out of the rest of this pass and potentially cause weird followup errors on subsequent passes that expect these operations to have been performed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's true, and I have a feeling that continuing with this pass will result in fewer weird cascading errors from this than returning here. Currently, it seems the only way to abort the pipeline is with a report_fatal_error, which currently raises a structured exception - which is way too harsh for something like this, and we should likely change report_fatal_error to throw a C++ exception, since we still have a chance of emitting a useful error message then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a feeling that continuing with this pass will result in fewer weird cascading errors from this than returning here
Actually bailing out early avoids crashes at least in some cases. Like for CS SV semantics, if we pass an invalid type like float
and let it continue with the lowering then it crashes in HLSignatureLower::GenerateDxilCSInputs()
in the below line.
// If the argument is of non-i32 type, convert here
if (newArg->getType() != NumTy)
newArg = Builder.CreateZExtOrTrunc(newArg, NumTy);
Based on the comments here, I agree we need a mechanism to stop further compilation when we generate errors. I suspect we would need that mechanism not just in this change, but probably at other places too where we generate errors. Therefore I created an issue #3496 to track this as a future enhancement that we would like to implement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's consistent with my later investigations. I approve of solving the larger problem right later.
...ck/hlsl/diagnostics/errors/semantics_type_checking/unsupported_types_cs_input_semantics.hlsl
Show resolved
Hide resolved
inputQual == DxilParamInputQual::OutIndices || | ||
inputQual == DxilParamInputQual::OutPrimitives || | ||
inputQual == DxilParamInputQual::OutputPatch || | ||
inputQual == DxilParamInputQual::OutVertices) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wish there was a better place to associate the input qualifier property with the expected array parameter shape (though this is a bit of an internal HL IR detail). Even if it was in its own function somewhere.
❌ Build DirectXShaderCompiler 1.0.4397 failed (commit d94d1319c7 by @vcsharma) |
include/dxc/DXIL/DxilSemantic.h
Outdated
}; | ||
|
||
enum class SizeClass { | ||
Scalar, | ||
Vec1, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't we treat Vec1 as Scalar? I think either one should be legal for all scalar system values, right? I see some that still only go up to Scalar, so does that mean those won't accept vec1? Why not?
Also, it would be nice to make the 0 enum value something like Invalid, or the Unknown. If Scalar aliased Vec1, then vector size would align with the enum values (always easier when looking at raw values, such as in debugger).
lib/DXIL/DxilSemantic.cpp
Outdated
@@ -126,7 +126,10 @@ Semantic::SizeClass Semantic::GetCompCount(llvm::Type* ty) const { | |||
return SizeClass::Unknown; | |||
|
|||
if (ty->isVectorTy()) { | |||
if (ty->getVectorNumElements() == 2) { | |||
if (ty->getVectorNumElements() == 1) { | |||
return SizeClass::Vec1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is where we could simply return Scalar, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Just to throw this into the mix, #5768 is related to this cadre of errors as well. We could use the means of defining what types go with what semantics here, but we wouldn't want to place it in the DxilSignature pass as this did. Rather, we should put it in Sema, possibly SemaHLSL DiagnoseEntry function. |
FXC reports error, but DXC only asserts.
Fixes #2299
Fixes #2954
Fixes #3444