<div dir="ltr"><span style="font-size:13.1999998092651px;line-height:19.7999992370605px">To chime in, I have been dealing with similar issue recently in the case of PNaCl which also uses a custom bitcode reader/writer. I was originally thinking about creating a custom backend for Le32 virtual architecture, but in the end I settled on the solution implemented entirely in Clang.</span><div style="font-size:13.1999998092651px;line-height:19.7999992370605px"><br></div><div style="font-size:13.1999998092651px;line-height:19.7999992370605px">I extended the ToolChain class by adding a `isVirtualTarget` method a created new Generic_BC (similar to the existing Generic_ELF) subclass which can be used by any target operating on bitcode. Any toolchain which inherits from Generic_BC behaves as if the -emit-llvm flag was on the command line (without actually having to pass this flag) and skips the Assembly phase, but still going through the Linking phase. To emit the PNaCl bitcode, we use a modified version of gold plugin to link all the bitcode files together and then run the PNaCl bitcode writer.</div><div style="font-size:13.1999998092651px;line-height:19.7999992370605px"><br></div><div style="font-size:13.1999998092651px;line-height:19.7999992370605px">I'm happy to submit this patch if you believe it would be useful to SPIR-V (or other targets with similar requirements).</div><br><div class="gmail_quote">On Tue, May 26, 2015 at 2:39 PM Neil Henning <<a href="mailto:llvm@duskborn.com">llvm@duskborn.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Daniel!<br>
<br>
So based on Philip and Chandler's points I really think the easiest way<br>
to integrate SPIR-V with LLVM is how I originally envisaged it - EG. we<br>
only put the production of SPIR-V within LLVM, and we integrate it fully<br>
as a backend.<br>
<br>
It was under this assumption that my comment of "don't regress tests" is<br>
valid - EG. we would be a normal backend like the other backends and<br>
would have a similar testing approach to the other backends. In this<br>
regard the changes you mentioned that David Blaikie is doing wouldn't in<br>
theory require any extra work on his or anyone else's part.<br>
<br>
I think if we follow this approach we provide the easiest method to<br>
integrate with LLVM, while putting no additional burden on the common<br>
infrastructure that is worrying the community so much :)<br>
<br>
Cheers,<br>
-Neil.<br>
<br>
On 26/05/15 22:22, Daniel Berlin wrote:<br>
> On Fri, May 22, 2015 at 9:29 AM, Philip Reames<br>
> <<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>> wrote:<br>
>> Let me start by emphasizing that I only speak for myself. This is my<br>
>> opinion, and nothing more.<br>
>><br>
>> On 05/22/2015 03:55 AM, Neil Henning wrote:<br>
>>> 'Maintenance and support obligations' - the only maintenance obligations<br>
>>> would be don't regress our tests when you change code, that is no different<br>
>>> from doing changes to any other target.<br>
>> I think SPIR as discussed is different in two potentially important ways:<br>
>> - The lack of target information. Can we even run IR passes over SPIR<br>
>> derived IR and get back valid SPIR? This hasn't been resolved.<br>
>> - SPIR has explicit compatibility provisions across versions. Adding a<br>
>> bi-directional converter makes the community responsible for preserving this<br>
>> compatibility, even in face of otherwise breaking IR changes. I haven't<br>
>> seen this clearly discussed yet.<br>
> Also, "don't regress tests" is a really strong obligation to impose if<br>
> "doing normal things to LLVM IR allowed by LLVM langref" may break<br>
> SPIR tests, because SPIR has stricter requirements and you test them<br>
> (and, if you don't test them, then the target is certain to break).<br>
> So as Philip says, this definitely sounds like something that needs<br>
> some real resolution.<br>
><br>
><br>
>>><br>
>>> Chandler raised some pretty important points in his reply, and we will<br>
>>> need to address them. In Sam's original email he did say 'We are open to the<br>
>>> SelectionDAG/MC approach if the community recommends it.' <- I would infer<br>
>>> from Chandler's email that he is most definitely recommending this, and if<br>
>>> the community as a whole believes this is the direction we should take then<br>
>>> we are happy to proceed in that way.<br>
>>><br>
>>> Really though our 'proposal' is that we have code that does bi-way<br>
>>> conversion from LLVM IR <-> SPIR-V,<br>
><br>
> And if you test this, as Philip says, the llvm community becomes<br>
> responsible for ensuring compatibility/figuring out ways to make this<br>
> translation into SPIR (which uh, AFAICT, was developed in part because<br>
> the llvm community didn't want to guarantee this :P).<br>
><br>
> How do you propose that work, exactly (literally, i'm not suggesting<br>
> it doesn't, i'm trying to understand the proposed moel)?<br>
><br>
> Let me give a practical example:<br>
><br>
> David Blaikie has been working on removing pointer types from some<br>
> places and adding them in others, to remove requirements to bitcast<br>
> pointers.<br>
><br>
> This requires bitcode changes, and IR/langref changes.<br>
><br>
> SPIR, even if it were to follow in the same path, does not in fact do<br>
> this right now.<br>
><br>
> In the LLVM bitcode/IR, one-way translation (from old bitcode to new)<br>
> from old to new is easy.<br>
> Two way translation from old to new is much harder (now he really has<br>
> to have a pass to output bitcasts where they don't exist now to match<br>
> the semantics of the old IR). But that is what is essentially going<br>
> to need to be done.<br>
><br>
> Thus, if you test the SPIR translation of LLVM load/stores/geps, you<br>
> would be affected by these changes.<br>
> Do you expect David to write that part of a conversion pass/or update<br>
> any existing conversion pass to make these changes to not break your<br>
> tests?<br>
><br>
> If so, you are asking the LLVM community to take on the burden of<br>
> supporting the SPIR serialization, essentially, and that will<br>
> significantly change the ability of the llvm community to innovate<br>
> LLVM's IR.<br>
> If not, what is the process you expect to be followed here?<br>
><br>
> IE do you expect him to break you, wait for SPIR to decide whether<br>
> they want to do the same thing, etc?<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div></div>