hctdb.py: Disabled validation allowed inconsistent dxil op signatures in same class

[tex3d]

Description
Validation in hctdb.py checking that operations sharing same OpCodeClass have the same function signature has never been enabled due one known conflict.

DIXL Operations for retrieving state from RayQuery and HitObject which share OpCodeClass were added without the benefit of this validation, and would have triggered a failure. Fortunately for these operations, the violation isn't critical, and the fix can be made to the definitions without changing the resulting DXIL IR.

Fortunately, more serious mistakes that had been made when adding operations in the past were caught before release. However, I think the validation should be re-enabled and these RayQuery and HitObject operations fixed to prevent these kinds of mistakes in the future.

I don't suggest fixing the original known conflict at the same time, since that would result in a change to DXIL IR. For this one, the validation should simply have an exception so it may still be run on all other operations.

Two other types of errors could occur, which aren't checked in the (disabled) validation. The function attributes could differ, or the overloads could differ on whether they are defined with "v" or using other overloads. Using different overloads for different operations is fine, but if an operation of the class is overloaded, another operation of the same class shouldn't use "v", as the overloaded versions should always use the overload type in one or more parameter or return types (like $o), while non-overloaded operations must not.

So, the validation should be updated to include this in the signature string as well.

Steps to Reproduce
Re-enable assertion here in hctdb.py, then add code to skip the one known conflict, or change it to emit an error for every conflict instead of just the first one.

DirectXShaderCompiler/utils/hct/hctdb.py

Lines 6136 to 6137 in ba86cc0

	# TODO: uncomment assert when opcodes are fixed
	# assert first_group == other_group, "overload signature %s for instruction %s differs from %s in %s" % (first.name, first_group, other.name, other_group)

Actual Behavior
This will reveal the next, previously unknown, conflict.

Background
DXIL groups operations (OpCode) using the same function into the same OpCodeClass. Operations in the same class must have the same arguments and properties, otherwise the function generated for one op would conflict with the same function when generated for another op in the same class. This can lead to subtle bugs, like incorrect function attributes applied leading to incorrect optimizations, but only with a certain combination and ordering of intrinsic calls.

hctdb.py has some code which is supposed to check the consistency of operations in the same class. However, it's been disabled since it was added due to one existing inconsistency, which has never been fixed. Fortunately, this known inconsistency wasn't breaking due to WavePrefixBitCount not being overloaded ("v"), and WavePrefixOp being overloaded. In this exceptional case, the two different signatures can coexist because one will always have an overload type added to the name and the other will not.