<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<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: 12pt;">>Right, what I was trying to say is that there are more benefits from</span><br>
</p>
<div>
<div class="PlainText" style="color: rgb(0, 0, 0); font-size: 10pt;"><span style="font-size: 12pt;">>having this not be a target than there is from having it be a target.</span></div>
<div class="PlainText" style="color: rgb(0, 0, 0);"><br>
</div>
<div class="PlainText">
<pre><font face="Helvetica"><font size="3"><span style="white-space: pre-wrap;">Please enumerate them, I have seen none posted so far . The implied “it is what all the the other backends do” w.r.t ISel/MC is at best(worst?) an implementation detail, and I’m still not quite sure why Chandler was so adamant about that. He seemed to imply that generating straight from the IR (as opposed to post legalisation?) introduces a direct dependance in the IR that the rest of LLVM would then be required to not break? I agree that the SPIRV backend should be insulated from changes the IR, although I’m not sure how to achieve that property. I’m also not sure how much, if at all, it would be susceptible to that to begin with. Deletions of instructions/attributes would obviously cause breakage and additions may cause unhandled and/or invalid combinations. I still don’t get the severity if this though, insight </span></font><span style="white-space: pre-wrap;">appreciated</span><font size="3"><span style="white-space: pre-wrap;">.</span></font></font></pre>
<div style="color: rgb(0, 0, 0);"><font face="Helvetica"><span style="white-space: pre-wrap;"><br>
</span></font></div>
<span style="color: rgb(0, 0, 0); font-size: 12pt;">>What you are proposing is a lot of work, and even if it does help to</span><br>
<span style="color: rgb(0, 0, 0); font-size: 12pt;">>avoid some duplicate work (which to be honest, I still don't quite</span><br>
<span style="color: rgb(0, 0, 0); font-size: 12pt;">>understand what duplication there would be if it weren't a target),</span><br>
<span style="color: rgb(0, 0, 0); font-size: 12pt;">>I don't think that is enough to justify the effort required.</span></div>
<div class="PlainText"><span style="color: rgb(0, 0, 0); font-size: 12pt;"></span><br>
<div style="font-family: Helvetica; font-size: 12px;"><span style="font-size: 12pt;">My point is that (modulo metadata, which I am still investigating better alternatives, and calling conventions) if SPIRV is a target, then a producer need not change their
compilation pipeline </span><i><span style="font-size: 12pt;">at all</span></i><span style="font-size: 12pt;"> to target SPIRV. There should be no effort required, it would come as a property of being a target. I think we are confusing each other again :(</span></div>
<div style="font-family: Helvetica; font-size: 12px;"><br>
</div>
<div style="font-family: Helvetica; font-size: 12px;"><span style="font-size: 12pt;">Leaving that aside for a moment, there are a number of advantages/requirements that, correct me if I’m wrong, would be impossible without a proper target.</span></div>
<div style="font-family: Helvetica; font-size: 12px;"><br>
</div>
<div style="font-family: Helvetica; font-size: 12px;"><span style="font-size: 12pt;">* Most critically: Intrinsics. I am almost certain that you would not accept the current mangling hacks, and if I am to support windows neither can I. Any solution would therefore
need to be able to register intrinsics and I believe this is impossible without a target (and even if it is, it makes less sense than a target that doesn’t use ISel/MC). Not being able to use intrinsics is a complete deal breaker.</span></div>
<div style="font-family: Helvetica; font-size: 12px;"><br>
</div>
<div><font face="Helvetica" size="3">*Basic optimisations (basic CSE,DCE,inlining): requires a TargetLibraryInfoImpl(?) which I believe requires a target. While not strictly necessary it would improve the </font><font face="Helvetica">readability</font><font face="Helvetica" size="3"> of
the resulting IR/SPIRV. </font><font face="Helvetica" size="3">All of the more complex optimisations would be done “post ingestion” of the SPIRV and with a different target triple so are unaffected by any decision made. See my reply to Hongbin for an approach.</font></div>
</div>
</div>
</div>
</body>
</html>