<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 12, 2018 at 2:55 PM Richard Smith via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div><div>I don't see how SPIR-V is any different from WebAssembly or PTXAS in this regard. I also don't see why a "whole backend" is a different amount of work from a separate program that implements a whole backend.</div><div> <br></div></div></div></div></blockquote><div><br></div><div>Our experience with WebAssembly (or really with its predecessors PNaCl and asm.js) was that it certainly is possible to do a reasonable implementation of TargetMachine and the related interfaces without using all of the common bits in lib/CodeGen that aren't suitable. However it does mean duplicating some of the functionality; for example when you skip SelectionDAG you end up having to re-implement a lot of the type legalization that happens during that stage. This was one of the top concerns we heard when we proposed upstreaming: people didn't want that duplication (and confusion about there being 2 different ways to do the same thing) even if the duplicated functionality was itself shared between projects. My observation was that one of the key things that got WebAssembly greater acceptance was our decision to use the lib/CodeGen pipeline. (I can't really say about NVPTX).</div><div><br></div><div>I think if you were principled about the design you could probably support a use case like SPIR-V in a reasonable way, but you'd need to convince stakeholders that things have changed (a lot changes over the period of years) and that the benefits justify the costs, etc.</div></div></div>