SLP/Loop vectorizer pass ordering

[James Molloy]

Hi Arnold,

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

Cheers,

James

From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] 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 grosser.es<mailto:tobias at grosser.es>> 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
reductions).



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: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140725/3762e552/attachment.html>