SLP/Loop vectorizer pass ordering

James Molloy James.Molloy at
Fri Jul 25 09:14:08 PDT 2014

Hi Arnold,

Wow, that’s pretty nasty! I’ll keep my eye on Hal’s scoped noalias stuff.



From: llvm-commits-bounces at [mailto:llvm-commits-bounces at] On Behalf Of Arnold Schwaighofer
Sent: 25 July 2014 17:10
To: Tobias Grosser
Cc: llvm-commits
Subject: Re: SLP/Loop vectorizer pass ordering

On Jul 25, 2014, at 8:48 AM, Tobias Grosser <tobias at<mailto:tobias at>> wrote:

On 25/07/2014 17:41, James Molloy wrote:

Hi Nadav, Arnold,

I've come across an interesting optimization problem in one of the SPEC
benchmarks. There is a loop that can be optimized by both the SLP vectorizer
and the loop vectorizer (when I patch the loop vectorizer to deal with fsub

The SLP vectorizer actually makes the performance worse - I think this is
due to a lack of loop unrolling afterwards. The Loop vectorizer can improve
the performance.

However, the loop vectorizer runs after the SLP vectorizer, so it never gets
a chance. I'd have thought the ideal order would be Loop Vectorizer -> SLP
vectorizer -> BB vectorizer, given that the loop vectorizer if it can run
will probably give greater speedup than SLP.

The current sequence is SLP vectorizer -> BB vectorizer -> Loop vectorizer.

Even though I was not directly addressed. I still reply.

The proposed new order is what I think makes most sense. I wonder what was the reason to go for the current order. Nadav, Arnold did you choose this order?

See my answer to James. We loose noalias information during inlining (until recently - thanks Hal for moving forward with the scoped noalias feature!).

We should absolutely evaluate moving the SLPVectorizer out of the inliner PM once we have working scoped noalias information.

Inlining could obscure patterns of parallelism the SLPVectorizer can recognize so their might be some losses - Erik’s work on making the SLPVectorizer more robust with respect to recognizing what schedules prevent vectorization plus work on recognizing more (possible mid-tree) patterns  should enable us to deal with some of the fallout I think.

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the llvm-commits mailing list