spvTextToBinary to return a mapping of textual ID names to numeric IDs about spirv-tools HOT 8 CLOSED

This would be nice to have, though it's not essential for checking the diagnostic messages even now. The message text around %IDs can be checked, and OpName instructions (where present) could be used to map %IDs to source names.

from spirv-tools.

Good point. I should be able to create diagnostic messages based on the (OpName) commands and verify the output using this approach.

from spirv-tools.

Keep in mind that OpName instructions are optional.
Also, the validator is checking binaries coming from any front end, which could be much more than the assembler in SPIR-V Tools.
So I see using the OpName values in validator diagnostics as nice-to-have, but not essential.

from spirv-tools.

Similarly, not every front end can furnish spvValidate() with a %ID mapping
proposed in OP.

On Thu, 3 Dec 2015 at 14:43 David Neto [email protected] wrote:

Keep in mind that OpName instructions are optional.
Also, the validator is checking binaries coming from any front end, which
could be much more than the assembler in SPIR-V Tools.
So I see using the OpName values in validator diagnostics as nice-to-have,
but not essential.

—
Reply to this email directly or view it on GitHub
#41 (comment)
.

Sent from a mobile device.

from spirv-tools.

I understand. I was plan on formatting the diagnostic message to display the id and only display the name if an OpName command references the ID. For example

No OpName

ID 32 has not been defined

With OpName

ID 32[foo] has not been defined

This should be pretty easy to implement. I can then use regex to parse the message to verify the unit tests.

from spirv-tools.

Yes, that would work.

Alternately, you could use the same strategy the assembler tests use: rely on the fact that the assembler assigns Id indices via a counter, starting at 1.

See, for example, some disassembler diagnostics tests at https://github.com/KhronosGroup/SPIRV-Tools/blob/master/test/BinaryToText.cpp#L181
Those tests first assemble some text, then disassemble text but fail with a message. (They use TextToBinaryTestBase::EncodeSuccessfullyDecodeFailed)

from spirv-tools.

That sounds like it would be dependent on the implementation. I wouldn't feel comfortable writing tests like that. It could also become complicated once we test more complicated cases.

from spirv-tools.

I'm not sure if there is anything to do here,spirv-dis does the name mapping when possible already. Can this be closed?

from spirv-tools.