[spirv-val] OpConstantNull refused for OpExtInst DebugTypeBasic

[Keenuts]

Hello!

Not sure if this is a validation issue, or a spec issue, or a desirable behavior, but if I do:

%flag = OpConstantNull %uint
        OpExtInst %void %-- DebugTypeBasic %-- %-- %-- %flag

I get a validation error because %flag is not an OpConstant.
This matches the spec which only mentions OpConstant.

Question is shall OpConstantNull %uint be considered to be the same as OpConstant %uint 0?
Or is that difference there by design?

(related to #5846 and llvm/llvm-project#118011)

[Keenuts]

@alan-baker I believe this is a validation error, probably a simple oversight on the added code, but in case I'm missing something?

[Keenuts]

Started to look into a code change for this, and seems there are quite a few tests cases where we check OpConstantNull is refused.
Example:

%ext = OpExtInstImport "NonSemantic.ClspvReflection.5"
%int = OpTypeInt 32 0
%null = OpConstantNull %int
%decl = OpExtInst %void %ext Kernel %foo %foo_name %null

This test expects a validation error to show because %null is not an OpConstant.
Those instruction indeed have a line like:

XX must be a 32-bit unsigned integer **OpConstant** composed with the bits of *some-table*.

Some extension have a valid flag with a value = to 0 (Kernel Property Flags) for ex.
I suspect if we apply the spec to the letter, OpConstantNull shall be rejected since it's another opcode? (Which is sad given the spec says OpConstantNull %int = 0)

[alan-baker]

I think strictly speaking, yes, it is disallowed. That might have been an oversight to simply disallow spec constants. There probably isn't much to gain by allowing it though unless every consumer handles OpConstantNull already.