<div dir="ltr">On 5 June 2013 11:59, David Tweed <span dir="ltr"><<a href="mailto:david.tweed@arm.com" target="_blank">david.tweed@arm.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-GB" link="blue" vlink="purple"><div class="im"><p class=""><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">(I've very rarely had O3 optimzation, rather than some program specific subset of the options, acheive any non-noise-level speed-up over O2  with gcc/g++.)</span><br>
</p></div></div></blockquote><div><br></div><div style>Hi David,</div><div style><br></div><div style>You surely remember this:</div><div><br></div><div><a href="http://plasma.cs.umass.edu/emery/stabilizer">http://plasma.cs.umass.edu/emery/stabilizer</a><br>
</div><div><br></div><div>"We find that, while -O2 has a significant impact relative to -O1, the performance impact of -O3 over -O2 optimizations is indistinguishable from random noise."</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-GB" link="blue" vlink="purple"><p class=""><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">Under that view, if the LLVM vectorizer was well enough understood I would think it would be good to include at O2. However, I suspect that the effects from having effectively two versions of each loop around are probably conflicting enough that it's a better decision to make O3 be the level at which it is blanket enabled.</span></p>
</div></blockquote><div></div></div><br></div><div class="gmail_extra" style>My view of O3 is that it *only* regards how aggressive you want to optimize your code. Some special cases are proven to run faster on O3, mostly benchmarks improvements that feed compiler engineers, and on those grounds, O3 can be noticeable if you're allowed to be more aggressive than usual. This is why I mentioned FP-safety, undefined behaviour, vectorization, etc.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>I don't expect O3 results to be faster than O2 results on average, but on specific cases where you know that the potential disaster is acceptable, should be fine to assume O3. Most people, though, use O3 (or O9!) in the expectancy that this will be always better. It not being worse than O2 doesn't help, either. ;)</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>I don't think it's *wrong* to put aut-vec on O2, I just think it's not its place to be, that's all. The potential to change results are there.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>cheers,</div><div class="gmail_extra" style>--renato</div></div>