<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 31, 2016 at 4:57 PM, Martin Peres <span dir="ltr"><<a href="mailto:martin.peres@free.fr" target="_blank">martin.peres@free.fr</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 31/05/16 10:42, Eero Tamminen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
On 30.05.2016 20:57, Rob Clark wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, May 30, 2016 at 1:39 PM, Matt Turner <<a href="mailto:mattst88@gmail.com" target="_blank">mattst88@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, May 30, 2016 at 10:28 AM, ⚛ <<a href="mailto:0xe2.0x9a.0x9b@gmail.com" target="_blank">0xe2.0x9a.0x9b@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This patch enables compilation with -flto.<br>
<br>
The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for glxgears.<br>
Performance changes in OpenGL games haven't been measured yet, my feeling is<br>
that they are negligible.<br>
</blockquote>
Without a compelling reason, I don't think the build system should be<br>
adding compiler flags like this.<br>
<br>
-flto makes debugging impossible, at least the last time I tried it<br>
with gcc. I don't think that's something we would want enabled<br>
whenever it's supported.<br>
</blockquote>
It would be interesting to know what gains it brings in scenarios less<br>
synthetic than glxgears..  my suspicion is that we have been doing<br>
manual lto forever (ie. use of static-inline fxn's where it matters).<br>
If it turns out to be a significant gain, I wouldn't be against it.<br>
Although perhaps only for non-debug builds..<br>
</blockquote>
Martin did some testing with LTO last year for a real customer 3D<br>
benchmark that was partly CPU bound.  In that case there were actually<br>
several percent performance improvements.<br>
</blockquote>
<br></span>
Definitely was the case on some machines. However, I used GCC 5.X to get it to work reliably and one GCC 5 release was clearly improving the performance.<br>
<br>
I stopped making LTO builds because it took too long to compile when bisecting performance issues.  I should try again now that gcc has "link-time parallelization (enabled using -flto=n)". If it scales with the number of threads, then linking mesa will not take 3 minutes anymore but ~45seconds or a normal quad core machine.<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>I did some tests on my work laptop earlier today (i7 Haswell Quad Mobile), and my build time from no LTO to -flto=8 went from 3m18s to do autogen.sh with arguments && make -j8 check to about 3m45s. This is with the GCC 5.3.1 that comes stock with ubuntu xenial (16.04).  The build overhead wasn't that bad, and the binary size reduction was pretty significant (35+MB to 17MB for i965_dri.so if memory serves). I haven't done benchmarks of the resulting executables yet, but I could if someone is interested in the results.<br><br></div><div>--Aaron<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
<br>
_______________________________________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
</div></div></blockquote></div><br></div></div>