<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 5, 2014 at 9:22 AM, Robert Lougher <span dir="ltr"><<a href="mailto:rob.lougher@gmail.com" target="_blank">rob.lougher@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 5 December 2014 at 17:09, David Chisnall <<a href="mailto:David.Chisnall@cl.cam.ac.uk">David.Chisnall@cl.cam.ac.uk</a>> wrote:<br>
> On 5 Dec 2014, at 16:02, Robert Lougher <<a href="mailto:rob.lougher@gmail.com">rob.lougher@gmail.com</a>> wrote:<br>
><br>
>> The blunt fact is that game<br>
>> developers don't like their loops being replaced and they want user<br>
>> control.  The real conversation I wanted was what form should this<br>
>> user control take.<br>
><br>
> This doesn't really make sense.  They're writing code in a high(ish)-level language and passing it to a compiler.  The processor doesn't understand C, so the compiler *must* replace it with something.  Whether that's a call to a library routine, a scalar loop, a vector loop, or a completely unrolled sequence depends on heuristics in the compiler.<br>
><br>
<br>
</span>Yes, but why isn't the user allowed any control over what the compiler does?<br></blockquote><div><br></div><div>Every bit of "control over what the compiler does" introduces extra complexity to the interface between the compiler and the user. It is essential for the maintainability of the compiler that the interface be kept as small as possible. The "hold the mayo" analogy is misleading because in the analogy the complexity of the user-"compiler" interface and the needs of maintainability of the compiler are neglected (or rather absorbed into the complexity of human-human interaction).</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> If they want full control of the machine instructions that are generated, then there is a mechanism for doing this: inline assembly.<br>
><br>
<br>
</span>Of course they could do this, but this is like having to make your<br>
deli sandwich yourself instead of telling the guy to "hold the mayo".<br>
<br>
Rob.<br>
<div class="HOEnZb"><div class="h5"><br>
> The complaint can't be that it's not generating the same code, it is that the compiler is generating something with performance characteristics that are difficult to reason about from the input code.  That's always a danger when you use an optimising compiler, but it looks like this case is a pretty extreme example.<br>
><br>
> David<br>
><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">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>
</div></div></blockquote></div><br></div></div>