Skip to content
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

Merged
merged 24 commits into from
Feb 26, 2021

Conversation

vcsharma
Copy link
Contributor

@vcsharma vcsharma commented Jul 16, 2020

FXC reports error, but DXC only asserts.

Fixes #2299
Fixes #2954
Fixes #3444

@vcsharma vcsharma requested review from tex3d and pow2clk July 16, 2020 01:48
@AppVeyorBot
Copy link

Copy link
Member

@pow2clk pow2clk left a 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.


if (isTypeDef || isLocalVar) {
self->Diag(semanticDecl->Loc, diag::err_hlsl_varmodifierna)
<< "semantic" << declarationType;
Copy link
Member

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very thorough! 👍

@vcsharma vcsharma changed the title Report error for unsupported types of CS input semantics Report error for unsupported types of SV semantics Jul 17, 2020
Copy link
Member

@pow2clk pow2clk left a 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

@AppVeyorBot
Copy link

Copy link
Member

@pow2clk pow2clk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! thanks!

@AppVeyorBot
Copy link

Copy link
Contributor

@tex3d tex3d left a 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.

if (qty->isArrayType())
return GetCompSize(GetArrayElementType(qty));
if (IsHLSLMatType(qty))
return GetCompSize(GetHLSLMatElementType(qty));
Copy link
Contributor

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.

@AppVeyorBot
Copy link

@AppVeyorBot
Copy link

@AppVeyorBot
Copy link

@AppVeyorBot
Copy link

Copy link
Member

@pow2clk pow2clk left a 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;
Copy link
Member

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Member

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.

inputQual == DxilParamInputQual::OutIndices ||
inputQual == DxilParamInputQual::OutPrimitives ||
inputQual == DxilParamInputQual::OutputPatch ||
inputQual == DxilParamInputQual::OutVertices) {
Copy link
Contributor

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.

@AppVeyorBot
Copy link

@AppVeyorBot
Copy link

};

enum class SizeClass {
Scalar,
Vec1,
Copy link
Contributor

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).

@@ -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;
Copy link
Contributor

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?

Copy link
Contributor

@tex3d tex3d left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@AppVeyorBot
Copy link

@vcsharma vcsharma merged commit bece3d4 into microsoft:master Feb 26, 2021
@vcsharma vcsharma deleted the bugfix branch February 26, 2021 00:38
tex3d added a commit to tex3d/DirectXShaderCompiler that referenced this pull request Mar 3, 2021
…#3043)"

This reverts commit bece3d4.

Revert system value type checking code due to regressions.
Will re-merge once it's fully verified fixed.
tex3d added a commit that referenced this pull request Mar 3, 2021
…3532)

This reverts commit bece3d4.

Revert system value type checking code due to regressions.
Will re-merge once it's fully verified fixed.
bob80905 pushed a commit to bob80905/DirectXShaderCompiler that referenced this pull request Apr 27, 2022
bob80905 pushed a commit to bob80905/DirectXShaderCompiler that referenced this pull request Apr 28, 2022
@pow2clk
Copy link
Member

pow2clk commented Sep 26, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants