Add SPIR-V NonSemantic.Shader.DebugInfo.200

[MrSidims]

It's based on NonSemantic.Shader.DebugInfo.100

New functionality compared to NonSemantic.Shader.DebugInfo.100
New instructions: DebugModule, DebugTypeSubrange,
DebugTypeArrayDynamic and DebugTypeString.

New Debug Operations.

DebugTypeArray no longer has an Component Count <id>
operand. It was replaced by a new operand <id>, <id>, ... Subranges to fully represent all characteristics of the
elements of DebugTypeArray.

Added an optional 'Target function' operand to
DebugFunction.

Added a 'SrcLang' table to be used by DebugCompilationUnit
instruction.

Signed-off-by: Sidorov, Dmitry dmitry.sidorov@intel.com

[MrSidims]

@baldurk hi, may I ask you to take a look? The patch adds new debug instructions, mostly for Fortran and also extends number of debug operations to match DWARF (though some of them require analog of .debug_address and hence are currently just placeholders).

Initially we called the extension as NonSemantic.Kernel.DebugInfo.100 to outline it as debug information for compute and to put less pressure for other vendors to implement it. If you want - this can be restored, but TBH having a single extension looks better.

[baldurk]

I don't think it's a good idea to make significant revisions to this extinst set after it has been released. Generally speaking that's avoided in vulkan and SPIR-V extensions to my knowledge and I think the ecosystem impact would be hard to predict.

I'd also point you to the original OpenCL.DebugInfo.100 extended instruction set, this one is intended for graphics and graphics shaders, so if you're doing OpenCL work that instruction set (or a new one based on it) is likely a better fit. That extension is also managed by Intel I believe so you might be able to discuss it internally too.

[bashbaug]

We've discussed this internally already and our current thinking is that a) it'd be better to use a non-semantic extended instruction set going forward vs. the original OpenCL.DebugInfo.100 extended instruction set, and b) it'd be nice to have one unified extended instruction set for debug information vs. two different extended instruction sets that are either potentially different or that we'd need to keep in sync.

We're open to suggestions how best to do this. Perhaps we should do a NonSemantic.Shader.DebugInfo.XYZ version instead (for some values of XYZ) so it is clear this is a newer version?

[baldurk]

In that case yes I think the best thing to do is make a new extended instruction set heavily based on this one, as this one was based on the OpenCL one. Either NonSemantic.Shader.DebugInfo.101 or NonSemantic.Shader.DebugInfo.200, whatever you think is best. Bear in mind though I don't expect the existing users of this set will update to it, so there's still going to be multiple sets in that sense (this version, any new version, and OpenCL.DebugInfo.100).

[MrSidims]

Thanks! Based on the feedback restored the original name of the instruction set.

[MrSidims]

Moved to draft for a while to figure out how to express virtuality.

[spencer-lunarg]

Now that we have a published NonSemantic.Shader.DebugInfo.101, can we go that route and add as much "additive" stuff here and make a NonSemantic.Shader.DebugInfo.102 instead?

It seems the only thing you can't "add" is DebugTypeArray but you could honestly make a DebugTypeArray2 at this point

It is going to MUCH easier to have tools "ignore" unknown things than having to manage 2 complete, 90% the same DebugInfo instruction sets

[MrSidims]

can we go that route and add as much "additive" stuff here and make a NonSemantic.Shader.DebugInfo.102 instead

Yes, it's on my TODO list to start porting few things to the rolling version of debug info. Though Fortran-specific things (like TypeArray) should probably be ported by somebody else who are interested in offloading of Fortran through SPIR-V :) . I'd keep this PR open for a while, also I don't expect .200 extension to be completely abandon for few reasons, which @vmaksimo might (or might not) comment on.