[DxilOp] Allow generation of illegal DXIL operations.

[python3kgae]

This change removes the IsOverloadLegal check in OP::GetOpFunc.

It will permit the generation of illegal DXIL operations. Subsequently, the validation should catch these illegal DXIL operations if they are not optimized later in SimplifyDxilCall.

Fixes #6410

[damyanp]

@llvm-beanz - can you have a look at this please? This is the more long-term solution to the issue we had with the 2403 release.

[pow2clk]

The description is no longer accurate as we're not moving it into an active DXASSERT

[python3kgae]

The description is no longer accurate as we're not moving it into an active DXASSERT

Fixed.

[pow2clk]

Per this comment: #6410 (comment) This revert should not "fix" #6410. I think the description and comments should be updated to reflect the removal of the assert as well.

[python3kgae]

Created #6566 and #6565 to track non-literal crashes.

[tex3d]

Created #6566 and #6565 to track non-literal crashes.

Looks good, though I think they shouldn't be considered crashes, since that's a temporary state of affairs that will change once this PR merges.

Also these issues don't cover the TODO comments in the test (// TODO: handle fp specials properly!). These are about the fact that we won't constant-fold generated literal DXIL ops if they produce FP exceptions (or FP specials), and we need to test specific expected results for operations involving FP specials. While issue #6557 is likely caused by this problem, it's about more than just this issue. I think we need another issue to track this problem. I had added a section for these to the fmod test when #6437 was initially created against the release branch. But I removed that section because it was disabled/unused and I wasn't sure if I got the expected results correct. This code could be used to craft a repro for an issue covering this TODO.

Here was the code:
d93ffad#diff-557ef4666494c6d42b516718ea7ed954e7e7153efc844f9dfd0678b9b53edb39R29-R42

[llvm-beanz]

Are #6566 & #6565 fixed with this change? From the surface those look like duplicates of #6410, but for different intrinsics, so I'm unsure why we have extra issues filed.

[python3kgae]

Are #6566 & #6565 fixed with this change? From the surface those look like duplicates of #6410, but for different intrinsics, so I'm unsure why we have extra issues filed.

No. current PR will not fix #6566 and #6565.
They fail for different reason which looks similar.

[llvm-beanz]

To clarify as we discussed in triage this morning. Once this change goes in the issues described originally as crashes in #6566 & #6565, revert to the pre-existing behavior of producing invalid DXIL that fails validation with a validator error.

Both issues are closed as per @damyanp's comment:

We have no plans to make changes in this area in DXC without considering a design that takes into account what the design is in Clang. For this reason I'm closing this issue as not planned.

[python3kgae]

Created #6566 and #6565 to track non-literal crashes.

Looks good, though I think they shouldn't be considered crashes, since that's a temporary state of affairs that will change once this PR merges.

Also these issues don't cover the TODO comments in the test (// TODO: handle fp specials properly!). These are about the fact that we won't constant-fold generated literal DXIL ops if they produce FP exceptions (or FP specials), and we need to test specific expected results for operations involving FP specials. While issue #6557 is likely caused by this problem, it's about more than just this issue. I think we need another issue to track this problem. I had added a section for these to the fmod test when #6437 was initially created against the release branch. But I removed that section because it was disabled/unused and I wasn't sure if I got the expected results correct. This code could be used to craft a repro for an issue covering this TODO.

Here was the code: d93ffad#diff-557ef4666494c6d42b516718ea7ed954e7e7153efc844f9dfd0678b9b53edb39R29-R42

Created #6567 to track the fp special value issue.

[pow2clk]

Just some changes to commments really.

[pow2clk]

Thanks!