[LLVMdev] Enabling the vectorizer for -Os

[Jeffrey Yasskin]

On Wed, Jun 5, 2013 at 5:51 PM, Nadav Rotem <nrotem at apple.com> wrote:
> Hi,
>
> Thanks for the feedback.  I think that we agree that vectorization on -Os
> can benefit many programs. Regarding -O2 vs -O3, maybe we should set a
> higher cost threshold for O2 to increase the likelihood of improving the
> performance ?  We have very few regressions on -O3 as is and with better
> cost models I believe that we can bring them close to zero, so I am not sure
> if it can help that much.   Renato, I prefer not to estimate the encoding
> size of instructions. We know that vector instructions take more space to
> encode. Will knowing the exact number help us in making a better decision ?
> I don’t think so. On modern processors when running vectorizable loops, the
> code size of the vector instructions is almost never the bottleneck.

You're talking about -Os, where the user has explicitly asked the
compiler to optimize the code size. Saying that the code size isn't a
speed bottleneck seems to miss the point.

>
> On Jun 5, 2013, at 6:09 AM, David Tweed <david.tweed at arm.com> wrote:
>
> On 5 June 2013 13:32, David Tweed <david.tweed at arm.com> wrote:
>
> This is what I'd like to know about: what specific potential to change
> results have you seen in the vectorizer?
>
>
> Ø  No changes, just conceptual. AFAIK, the difference between the passes on
> O2 and O3 are minimal (looking at the code where this is chosen) and they
> don't seem to be particularly amazing to warrant their special place in On
> land.
>
> Ø  If the argument for having auto-vec on O2 is that O3 makes no difference,
> than, why have O3 in the first place? Why not make O3 an alias to O2 and
> solve all problems?
>
> I think I'm managing to express myself unclearly again L For me the
> practical definition of "O2" is "do transformations which are pretty much
> guaranteed to actually be optimizations" rather than "do all optimizations
> which don't carry a risk of disaster".  In which case the argument for or
> against vectorizing at O2 is whether it's " pretty much guaranteed to
> actually be an optimization" or not rather than whether it's an aggressive
> optimization or not. I wouldn't say the argument for auto-vec on O2 isn't
> that O3 makes no difference, it's whether the intrinsic properties of
> auto-vec pass fit with the criteria which one uses for enabling passes at
> O2. I think you were suggesting that "aggressive" transforms don't belong in
> O2  and auto-vec  is "aggressive", while I tend to think of
> simplicity/performance-relaiblity as the criteria for O2 and it's unclear if
> auto-vec fits that.
>
> Cheers,
> Dave
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>