[LLVMdev] RFB: Would like to flip the vector shuffle legality flag
Quentin Colombet
qcolombet at apple.com
Tue Jan 27 12:58:13 PST 2015
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> 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> wrote:
> Hi Chandler,
>
> On Fri, Jan 23, 2015 at 8:15 AM, Chandler Carruth <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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150127/9f7fc94a/attachment.html>
More information about the llvm-dev
mailing list