<div dir="ltr">On 8 April 2013 19:41, Iain Buclaw <span dir="ltr"><<a href="mailto:ibuclaw@ubuntu.com" target="_blank">ibuclaw@ubuntu.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div class="h5"><div class="gmail_extra"><div class="gmail_quote">On 8 April 2013 10:06, Timon Gehr <span dir="ltr"><<a href="mailto:timon.gehr@gmx.ch" target="_blank">timon.gehr@gmx.ch</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 04/08/2013 10:29 AM, Iain Buclaw wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
On 6 April 2013 12:09, bearophile <<a href="mailto:bearophileHUGS@lycos.com" target="_blank">bearophileHUGS@lycos.com</a><br></div><div><div>
<mailto:<a href="mailto:bearophileHUGS@lycos.com" target="_blank">bearophileHUGS@lycos.<u></u>com</a>>> wrote:<br>
<br>
I remember Walter saying two or more times that the semantics of D<br>
offers some optimization opportunities that probably are not yet<br>
used to try to reduce the run-time of D programs. Is Walter willing<br>
to write down a list of such opportunities? (Ideas from other<br>
persons are welcome). Maybe some LDC/GDC developer will make the<br>
GCC/LLVM back-ends use them. The implementation of those ideas will<br>
require some time, so later it's better to put the list in the D wiki.<br>
<br>
Bye,<br>
bearophile<br>
<br>
<br>
<br></div></div><div>
This information could possibly be helpful. Though given that most of<br>
(gdc) codegen is on par with g++, there's probably not much on the list<br>
that isn't already detected by the backend optimisation passes.<br>
<br>
<br>
--<br>
Iain Buclaw<br>
<br>
*(p < e ? p++ : p) = (c & 0x0f) + '0';<br>
</div></blockquote>
<br>
Does GDC use the additional type information for optimization? Eg. if something is immutable, then aliasing issues do not have to be considered for it when reading and writing through multiple pointers repeatedly.<br>
</blockquote></div><br></div></div></div><div class="gmail_extra">It uses some type information, eg:<br><br></div><div class="gmail_extra">const/immutable/wild -> qualified const.<br></div><div class="gmail_extra">shared -> qualified volatile.<br>
</div><div class="gmail_extra">shared + const/wild -> qualified const/volatile.<br clear="all"></div><div class="gmail_extra"><br><br></div><div class="gmail_extra">Done nothing in regards to C 'restrict' optimisations. However the D array .ptr type could also be considered 'restrict' also.<br>
</div></div></blockquote><div><br></div><div style>Yes, I was just about to bring up __restrict, there is probably good opportunity for that.</div><div style>Why do you suppose .ptr is restrict? One problem with D's slicing is it's very hard to assume __restrict on basically any arrays.</div>
<div style>I feel like 'scope' might imply a __restrict input... although the relationship is kinda backwards, so maybe not...</div><div style><br></div><div style>How about pure? Is GDC able to factor pure function calls with the same arguments outside of loops, or eliminate consecutive calls? It's really tedious to do this by hand, and breaks code continuity. Particularly important in a language that supports properties, since they'll be accessed consecutively all the time.</div>
<div style><br></div><div style>What about immutable? You said it qualifies const, which in C++ is absolutely meaningless in terms of optimisation potential; just because something is const, the source of the pointer can certainly be non-const somewhere else, which means C++ can't possibly factor const loads outside of loops, and must respect consecutive dereferences of the same pointer.</div>
<div style>immutable in D should certainly be able to be factored outside loops, so it is more meaningful than const, and actually has real optimisation potential. Can GCC actually express an immutable value?</div><div style>
<br></div><div style>I remember there was a problem a while back that I brought to you about GDC generating stack frames unnecessarily for leaf functions, is that resolved? I haven't checked in a while.</div><div style>
<br></div><div style>Does GDC have access to a GDC-specific __restrict attribute to tag stuff manually? I'm struggling to think where it can be automated...</div></div></div></div>