<div dir="ltr">I've been using lto for the past several weeks not for performance reasons but to reduce the resulting binary size which has grown to be rather substantial.  I usually set "-flto -ffat-lto-objects -flto-odr-type-merging" in the CFLAGS and CXXFLAGS env vars prior to configure and have yet to experience any problems with the files in mapi./<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">- Chuck<br></div></div></div>
<br><div class="gmail_quote">On Tue, May 31, 2016 at 3:42 AM, Eero Tamminen <span dir="ltr"><<a href="mailto:eero.t.tamminen@intel.com" target="_blank">eero.t.tamminen@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<span class=""><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>
<br>
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>
<br>
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>
<br></span>
Martin did some testing with LTO last year for a real customer 3D benchmark that was partly CPU bound.  In that case there were actually several percent performance improvements.<br>
<br>
How much, depends on:<br>
- How CPU bound the 3D benchmark is and do those CPU bottlenecks hit cases where LTO can actually help<br>
- What's the CPU/GPU balance on the given given HW<br>
  (more visible on more CPU bound HW)<br>
- What GCC version is used<br>
  (newer GCC versions provide more benefit with LTO)<br>
<br>
And it should not hurt performance (at least if one is using "performance" frequency policy, or fixed CPU frequency, instead of "powersave" one.  "Powersave" can drop CPU frequency dramatically when use-case drop its CPU usage and large enough CPU freq drop can make things slower).<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
        - Eero</font></span><div class="HOEnZb"><div class="h5"><br>
<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>