<div dir="ltr">Sorry for coming late to the thread, I was traveling and then quite sick, and am trying to catch up on things.<div><br></div><div>I'm generally in favor of having a SPIR-V target in upstream LLVM. There have been lots of folks on the thread that have indicated the many reasons this is advantageous. I agree with them.</div><div><br></div><div>However, I have a few of concerns about exactly how this is implemented that I want to bring up.</div><div><br></div><div>1) I don't think this should live along side lib/Bitcode. For better or worse, doing that would make it *the* LLVM stable program serialization framework, and I'm at least *very* uncomfortable with that at this stage. SPIR-V was developed by a party outside of the LLVM community, and I don't really know why we should consider it to be a viable canonical stable serialization format. I think it makes much more sense for it to be clearly *optional* (the way a "Target" in LLVM is today) and predicated on an external spec (the way a "Target" in LLVM is today). From this perspective, all of the "Target" machinery in LLVM is actually exactly right -- it can be optional, it can be omitted, and wired up to a triple, etc.</div><div><br></div><div>2) I think we need to be really careful about exactly what the mechanism is that it uses to serialize. I realize that the SelectionDAG is a pretty terrible fit for what SPIR-V wants to do, but skipping it has a significant problem. Currently, we have a legalization framework in the SelectionDAG. If I add a new type or a new operation to LLVM and I can generically type legalize or expand it into other operations, I don't have to update every single target (some of which I may not know anything about) to support that construct. I think it is critical to preserve this contract even with SPIR-V. Currently, this could be done easily just by abusing in a minor way the legalization facilities of SelectionDAG. I'd love it if we had a more isolated legalization framework we could use instead, but I'd like to not grow *two* legalization frameworks that the LLVM community (that is, not the SPIR-V maintainers) have to update when making general IR changes. I'm not sure what the best approach is here, but I think it's really critical to clearly and directly address this problem.</div><div><br></div><div>To give you an idea of what I'm worried about in #2, imagine that we both extend the IR to support some new construct, *and* we make that new construct *canonical*. This would cause the existing IR produced by frontends to optimize into something that the SPIR-V "target" wasn't prepared for and would have to be taught about to continue passing its basic tests. I would like for teaching the SPIR-V "target" to not be a completely separate overhead from teaching the actual machine targets about this, which we usually do today by providing an obvious legalization strategy for the new construct to the SelectionDAG and falling back to that on most targets.</div><div><br></div><div>I'm somewhat worried about this due to changes to the IR *operations*, but I'm actually more worried about changes to the IR *types* or even *type systems*. If the SPIR-V stuff doesn't do type legalization of some form, and we want to change the fundamental way LLVM deals with (for example) FCAs (whether to get rid of them, or handle them in a "better" way, or whatever), then I'm worried adding SPIR-V will add more road blocks to something that is already really hard. That doesn't seem like the right design to me.</div><div><br></div><div><br></div><div><br></div><div>All that said, I think it is totally fine to put the "frontend" which reads in SPIR-V and produces IR ... really wherever you want. It could live inside the "Target" as some have suggested or somewhere else. Having it live inside the "Target" would have some advantages of making it easy to exclude from a build if folks aren't using it (for whatever reason).</div><div><br></div><div>-Chandler</div></div>