[SPIR-V] OpConstantNull Result Type <id> '12[%type_2d_image]' cannot have a null value

[webez]

Description
Invalid spirv generated when calling a function that returns a texture depending on a condition

Steps to Reproduce

Shader Playground

Actual Behavior
fatal error: generated SPIR-V is invalid: OpConstantNull Result Type '12[%type_2d_image]' cannot have a null value.
%13 = OpConstantNull %type_2d_image

Environment
DXC Trunk, no optimization

[Keenuts]

Hi!

Thanks for the report & nice catch!
For some reasons when the return is not defined for a branch (here the compiler don't know both branches of the if/else returned), we generate an OpConstantNull instead of an OpUndef.
I'll fix that.

[s-perron]

@Keenuts See if you can find the reason in the history. I prefer using OpConstantNull when possible because if that code is triggered, it will give consistent results. That would be easier to debug. For types where OpConstantNull is not allowed, using undef is a good.

[Keenuts]

Original addition was #809
There don't seem to be any mention of why this was done.

As for using OpConstantNull instead: I would be against: the OpUndef has the advantage to be clear: it is not a desired value. Meaning we can do static analysis on the SPIR-V, and possibly find cases where there is a bug. If we use OpConstantNull, then we cannot differentiate actual null from bugs.