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

[Daniel Berlin]

On Fri, May 22, 2015 at 9:29 AM, Philip Reames
<listmail at philipreames.com> wrote:
> Let me start by emphasizing that I only speak for myself.  This is my
> opinion, and nothing more.
>
> On 05/22/2015 03:55 AM, Neil Henning wrote:
>>
>> 'Maintenance and support obligations' - the only maintenance obligations
>> would be don't regress our tests when you change code, that is no different
>> from doing changes to any other target.
>
> I think SPIR as discussed is different in two potentially important ways:
> - The lack of target information.  Can we even run IR passes over SPIR
> derived IR and get back valid SPIR?  This hasn't been resolved.
> - SPIR has explicit compatibility provisions across versions. Adding a
> bi-directional converter makes the community responsible for preserving this
> compatibility, even in face of otherwise breaking IR changes.  I haven't
> seen this clearly discussed yet.

Also, "don't regress tests" is a really strong obligation to impose if
"doing normal things to LLVM IR allowed by LLVM langref" may break
SPIR tests, because SPIR has stricter requirements and you test them
(and, if you don't test them, then the target is certain to break).
So as Philip says, this definitely sounds like something that needs
some real resolution.


>>
>>
>> Chandler raised some pretty important points in his reply, and we will
>> need to address them. In Sam's original email he did say 'We are open to the
>> SelectionDAG/MC approach if the community recommends it.' <- I would infer
>> from Chandler's email that he is most definitely recommending this, and if
>> the community as a whole believes this is the direction we should take then
>> we are happy to proceed in that way.
>>
>> Really though our 'proposal' is that we have code that does bi-way
>> conversion from LLVM IR <-> SPIR-V,


And if you test this, as Philip says,  the llvm community becomes
responsible for ensuring compatibility/figuring out ways to make this
translation into SPIR (which uh, AFAICT, was developed in part because
the llvm community didn't want to guarantee this :P).

How do you propose that work, exactly (literally, i'm not suggesting
it doesn't, i'm trying to understand the proposed moel)?

Let me give a practical example:

David Blaikie has been working on removing pointer types from some
places and adding them in others, to remove requirements to bitcast
pointers.

This requires bitcode changes, and IR/langref changes.

SPIR, even if it were to follow in the same path, does not in fact do
this right now.

In the LLVM bitcode/IR, one-way translation (from old bitcode to new)
from old to new is easy.
Two way translation from old to new is much harder (now he really has
to have a pass to output bitcasts where they don't exist now to match
the semantics of the old IR).  But that is what is essentially going
to need to be done.

Thus, if you test the SPIR translation of LLVM load/stores/geps, you
would be affected by these changes.
Do you expect David to write that part of a conversion pass/or update
any existing conversion pass to make these changes to not break your
tests?

If so, you are asking the LLVM community to take on the burden of
supporting the SPIR serialization, essentially, and that will
significantly change the ability of the llvm community to innovate
LLVM's IR.
If not, what is the process you expect to be followed here?

IE do you expect him to break you, wait for SPIR to decide whether
they want to do the same thing, etc?