<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif;" dir="ltr">
<p><span style="font-size: 10pt;">>So there are really two questions here:</span><br>
</p>
<div style="color: rgb(0, 0, 0);"><font size="2"><span style="font-size:10pt;">
<div class="PlainText">>1. Should targets be required to use SelectionDAG/GlobalISEL ?<br>
>2. Should SPIR-V use SelectionDAG/GlobalISel?<br>
><br>
>In my opinion, regardless of the answer to question #1, the answer<br>
>to question #2 is no, SPIR-V should not use SelectionDAG/GlobalISel.<br>
<br>
Yes I have come the same conclusion when I saw how much type information was lost.</div>
<div class="PlainText"><br>
>I touched on this before in previous emails, but the main problem is that<br>
>SelectionDAG (and GlobalISel to a lesser extent) plus the whole MachineInstr<br>
>layer is a much lower-level representation than SPIR-V, so you will<br>
>need to do a lot of extra work and/or modifications to existing<br>
>infrastructure in order to get a working target, and even then<br>
>you may be limited to emitting poor quality SPIR-V that other<br>
>backends will have a hard time optimizing.<br>
><br>
>With all this work, what advantages are you getting? If the<br>
>only reason to do it this way is so you can use intrinsics,<br>
>or TargetLibraryInfo, or easier integration with other tools,<br>
>I think it would be better to try to save the effort and try<br>
>to solve those problems in some other way.<br>
<br>
I didn't really want to do that in the first place, but your responses and Chandler's </div>
<div class="PlainText">reply in the previous RFC made it seem an absolute requirement. <br>
<br>
>LLVM IR -> SPIR-V directly will give you better code, lower compile<br>
>times. It will be more simple and easier to maintain, and you will<br>
>be able to re-use existing SPIR-V parsers/writers that exist<br>
>in SPIRV-Tools.</div>
<div class="PlainText"><br>
</div>
<div class="PlainText">
<div class="PlainText">Yes the current approach seems to be the place that has the most type info.</div>
<div class="PlainText">(aside the AST of the producer, but that is a non sequitur, because what </div>
<div class="PlainText">would we be building a backend for?). </div>
<div class="PlainText">The parser and writer already exist <span style="font-size: 10pt;">in the code base</span><span style="font-size: 10pt;">, as</span><span style="font-size: 10pt;"> </span><span style="font-size: 10pt;">do</span><span style="font-size: 10pt;"> </span><span style="font-size: 10pt;">the</span></div>
<div class="PlainText"><span style="font-size: 10pt;">interconversions between LLVM <->SPIR-V, </span><span style="font-size: 10pt;">so the only use would </span></div>
<div class="PlainText">be for the verifier for testing. I mean I could replace them, but that </div>
<div class="PlainText">is effort for nothing</div>
<br>
>This goes back to something I mentioned in my original email, but <br>
>I really think the best thing to do for this project right now is to<br>
>keep it separate from LLVM, clean up the code, and try to get people<br>
>using it. It's going to be much easier to get this upstream in LLVM or<br>
>even convince people that the answer to question #1 should be 'no' if we<br>
>have a code base that is mature, well supported, and has a healthy<br>
>userbase.</div>
<div class="PlainText"><br>
The purpose of this thread is to notify the community that I am working on</div>
<div class="PlainText">this so that there ends up only one proposal and we don't waste effort.</div>
<div class="PlainText"><br>
</div>
<div class="PlainText">I'll definitely polish and test thoroughly once I get intrinsics and the rest of </div>
<div class="PlainText">the tablegen stuff done. </div>
<div class="PlainText">I hope to get a large user base but this is sort of chicken and egg.<br>
Keeping it separate is not a viable longterm solution and is the primary reason</div>
<div class="PlainText">why I want to upstream it eventually.<br>
<br>
>You don't need to register intrinsics to be able to use them, and<br>
>it's also possible to register them without a backend, but this has not<br>
>been done before.<br>
<br>
"Hasn't been bone" in an encouraging way, or not?<br>
And you base them on what, the collection of triples? </div>
<div class="PlainText">(i.e. spirv: 32-bit OpenCL, spirv64: 64-bit OpenCL and possibly a Vulkan one </div>
<div class="PlainText">if/when I have an idea on what to do with the (lack of) layout)</div>
<div class="PlainText"><br>
</div>
<div class="PlainText">Irrespectively my fork will stay a target for now.<br>
<br>
>You don't need a target for this. TargeLibraryInfo is constructed<br>
>based on the triple.<br>
<br>
Ah, OK, maybe it was that there wasn't a triple independent one available</div>
<div class="PlainText">for the really simple operations when I was trying to enable it.</div>
<div class="PlainText"><br>
</div>
<div class="PlainText">Thanks,</div>
<div class="PlainText">Nic<br>
<br>
</div>
</span></font></div>
</div>
</body>
</html>