[LLVMdev] Enabling the vectorizer for -Os

[Renato Golin]

On 5 June 2013 11:59, David Tweed <david.tweed at arm.com> wrote:

> (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++.)
>

Hi David,

You surely remember this:

http://plasma.cs.umass.edu/emery/stabilizer

"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."

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.
>

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.

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. ;)

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.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130605/77c08cdb/attachment.html>