[LLVMdev] [RFC] Upstreaming LLVM/SPIR-V converter

[Chandler Carruth]

Sorry for coming late to the thread, I was traveling and then quite sick,
and am trying to catch up on things.

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.

However, I have a few of concerns about exactly how this is implemented
that I want to bring up.

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.

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.

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.

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.



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).

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150521/e247e681/attachment.html>