Design Questions about rspirv

[antiagainst]

Hey @aioob, thanks for your interest and certainly appreciate if you can contribute! :)

1. The data representation is intended to faithfully represent the SPIR-V binary module at a low-level for data inspection; while the structured representation is intended to represent the SPIR-V module at a high-level structured way to facilitate transformations. The former is suitable for use by disassemblers and trivial analyses where we don't really need to trace through an instruction chain for information; while real optimizations will need to do that frequently so we need to connect related instructions more tightly. The former guarantee roundtrip while the latter does not (it's intended for transformation anyway). I think there is also historical reasons. I initially only planed the data representation part with the parser and its consumer. It's much more easier to use the data representation as the format handed back by the parser to the consumer and defer all the complicated logic to the consumer itself, instead of trying to build the whole IR inside the parser. It's more complicated so we need the full picture so we cannot invoke the consumer after decoding each instruction, and not all consumers need that anyway. I guess I don't have strong preference to always keep these two representations. But given data representation is basically there and we are still developing structured representation, I think they will co-exist for a while. We can re-evaluate the situation after we have a more full-fledged structured representation. :)
2. I listed a few potential use cases in the master README. Util now, the only concrete use case that I've realized is a SPIR-V disassembler (if we think the parser is a neural API that can serve many use cases). javelin is the current use case that we are trying to support. I'm happy to facilitate others interested. The API (structured representation) should generally be guided by proved compiler practices so that they can serve different use cases.
3. I think the parser should only do the minimal structural validation; that is, must-have validation to correctly parsing the SPIR-V binary. We can view the parser as a deserialization tool. I prefer to have all other validations happening in a later stage. The benefits is that we have a clear separation of concerns and better layering. Besides, the error message can potentially be much better at a later stage when we have the full picture.

I hope the above is helpful. Let me know if there are unclear points. :)

[Skepfyr]

Thank you very much, that's cleared up all the questions I have (so far!).