[LLVMdev] RFB: Would like to flip the vector shuffle legality flag (original) (raw)

Kuperstein, Michael M michael.m.kuperstein at intel.com
Wed Jan 28 07:57:28 PST 2015

Same here - it looks mostly neutral. I don't think we see anything that's significantly above or below noise.

From: Quentin Colombet [mailto:qcolombet at apple.com] Sent: Tuesday, January 27, 2015 22:58 To: Chandler Carruth Cc: Andrea Di Biagio; Simon Pilgrim; Sanjay Patel; LLVM Developers Mailing List; Kuperstein, Michael M Subject: Re: RFB: Would like to flip the vector shuffle legality flag

Hi Chandler,

I ran the new flag through some of our internal benchmarks and overall this is neutral, so slightly better. I observed a couple of improvements, but also a couple of regressions. I am working on tracking those down to produce reduced test cases. No sure I would have time to do that by the end of this week though.

Cheers, -Quentin

On Jan 25, 2015, at 2:15 PM, Sanjay Patel <spatel at rotateright.com<mailto:spatel at rotateright.com>> wrote:

I ran the benchmarking subset of test-suite on a btver2 machine and optimizing for btver2 (so enabling AVX codegen).

I don't see anything outside of the noise with x86-experimental-vector-shuffle-legality=1.

On Fri, Jan 23, 2015 at 5:19 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com<mailto:andrea.dibiagio at gmail.com>> wrote: Hi Chandler,

On Fri, Jan 23, 2015 at 8:15 AM, Chandler Carruth <chandlerc at gmail.com<mailto:chandlerc at gmail.com>> wrote:

Greetings LLVM hackers and x86 vector shufflers!

I would like to flip on another chunk of the new vector shuffling, specifically the logic to mark ~all shuffles as "legal". This can be tested today with the flag "-x86-experimental-vector-shuffle-legality". I would essentially like to make this the default (by removing the "false" path). Doing this will allow me to completely delete the old vector shuffle lowering. I've got the patches prepped and ready to go, but it will likely have a significant impact on performance. Notably, a bunch of the remaining domain crossing bugs I'm seeing are due to this. The key thing to realize is that vector shuffle combining is much more powerful when we think all of these are legal, and so we combine away bad shuffles that would trigger domain crosses.

That's good news! Also, I really like your idea of making all shuffles legal by default. I remember I did some experiments disabling the checks for legal shuffles in the DAGCombiner to see how well the new shuffle lowering coped with 'overly' aggressive shuffle combining. I was surprised to see that from eyeballing the generated code it looked much cleaner (although I didn't test it extensively). Our target is btver2, so I also didn't look at what could have been codegen for targets with no AVX/SSE4.1 where there might be fewer opportunities to match a shuffle with a single target instruction during legalization.

All of my benchmarks have come back performance neutral overall with a few benchmarks improving. However, there may be some regressions that folks want to track down first. I'd really like to get those reported and prioritize among the vector shuffle work so we can nuke several thousand lines of code from X86ISelLowering.cpp. =D

I'll see if I can get some numbers from our internal codebase and help with reporting potential regressions.

Thanks, Andrea

Thanks! -Chandler

PS: If you're feeling adventurous, the next big mode flip flag I want to see changed is -x86-experimental-vector-widening-legalization, but this is a much more deep change to the entire vector legalization strategy, so I want to do it second and separately.

Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150128/78e1a51b/attachment.html>

More information about the llvm-dev mailing list