<div dir="ltr"><div><div><div><div><div>Note that I am most definitely speaking for myself and these views may not map with my employers view.<br><br></div>I've also seen some interesting work on reducing energy usage, particularly in embedded systems which actually have the ability to power down individual memory banks: in this case carefully organising things may mean that it's possible to completely power down all but one bank and save a quite significant amount of energy. (This isn't the paper I'm thinking about, but similar "Optimizing the memory bandwidth with loop fusion", Paul Marchal, Jose Ignacio Gomez and Francky Catthoor.) However, all these "big win"<br>
</div>changes seem to only be practically feasible if you're working at a higher level like a DSL where you actually have a stronger model of what the program is doing to reason with; it seems likely to me that any optimizations you can figure out (in terms of correctness and profitability) at the LLVM-IR level are likely to have at least an order of magnitude less effect than higher level transformations. There's the counterargument that IR optimizations can automatically be applied to all code from any LLVM front-end, but I'm still unsure it's worth the practical effort given the likely reward.<br>
<br></div>Indeed, one of my concerns when I'm using LLVM is that after having carefully analysed and determined doing something which yields slightly odd IR but would actually be profitable in terms of one or more of latency, memory bandwidth or energy usage, that the LLVM optimizers might go and undo it...<br>
<br></div>Cheers,<br></div>Dave<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 16, 2013 at 9:53 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 15 Apr 2013, at 16:03, Sean Silva <<a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>> wrote:<br>
<br>
> See <a href="http://llvm.org/bugs/show_bug.cgi?id=6210" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=6210</a>.<br>
<br>
Chris is correct at the coarse granularity, but there are some trades to be made at the fine.  There is some interesting work from MIT in the context of image processing kernels related to the relative costs of saving intermediates out to cache or DRAM vs recomputing them - often recomputing takes one to two orders of magnitude less power.  The tile hashing mechanism in recent MALI GPUs is designed to address the same problem: accesses to memory - especially off-chip memory - use a surprisingly large amount of power.<br>

<br>
Optimising for this requires quite intimate knowledge of the target CPU (sizes of the caches, relative costs of ALU operations to cache / DRAM accesses, and so on), but it would be very interesting if a compiler had this knowledge and could take advantage of it.<br>

<br>
I don't know of any work using LLVM to do this (the MIT work was based on source-to-source transformations via a C++ DSL), but it would certainly be interesting to any company that shipped a large number of mobile devices based on a small number of distinct SoCs.  If only there were such a company that regularly contributed to LLVM...<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>
</blockquote></div><br><br clear="all"><br>-- <br><div>cheers, dave tweed__________________________</div><div>high-performance computing and machine vision expert: <a href="mailto:david.tweed@gmail.com" target="_blank">david.tweed@gmail.com</a></div>
<div>"while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot</div><div> </div>
</div>