[LLVMdev] Enabling the vectorizer for -Os

[Nadav Rotem]

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. 

Thanks,
Nadav


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130605/b52ff794/attachment.html>