[PATCH] Fix PR19657 : SLP vectorization doesn't combine scalar load to vector loads

[Karthik Bhat]

Thanks Nadav, Eric for the comments. Yes adding a flag seems a good option.
I will also look into suggestions from nadav and modify the patch and get
back shortly.
Thanks for valuable inputs and spending time on this.
Regards
Karthik Bhat


On Tue, May 20, 2014 at 2:28 AM, Eric Christopher <echristo at gmail.com>wrote:

> On Mon, May 19, 2014 at 1:53 PM, Nadav Rotem <nrotem at apple.com> wrote:
> >
> > On May 19, 2014, at 1:40 PM, Eric Christopher <echristo at gmail.com>
> wrote:
> >
> >>>
> >>> I like your idea of adding a flag to control the performance/compile
> time tradeoff.  One place that could benefit from this flag is the part of
> the code where we sort the store instructions. In order to reduce the
> compile time we place the sorts in small buckets and sort them
> individually. Increasing the size of the buckets can allow more
> vectorization opportunities. Another place is the consecutive memory
> address tests where we could throw in a few more checks.
> >>>
> >>
> >> *nod*
> >>
> >>> My main concern with the patch in this thread is that it duplicates a
> ton of code. The most complicated part of the SLP-vectorizer is the
> recursion that scans the tree and duplicating that code just to change a
> few lines will make it unmaintainable. I also suspect that this is not the
> correct approach to solving this problem, but I must admit that I did not
> look at the problem carefully.
> >>>
> >>
> >> Sure, I just didn't want to reject the idea out of hand as you seemed
> >> to be doing because it might increase compile time. Having the pass
> >> check the opt level when it's running is pretty easy.
> >
> > My main concern is the duplication of hundreds of lines of code. I agree
> with your suggestion to enable high compile time optimizations for some
> opts level and I think that we should move forward with this idea where it
> makes sense. Did you get a chance to look at the two places that I
> suggested to change?
> >
>
> Not my patch :) I'll let Karthik handle that part.
>
> -eric
>
> > -N
> >
> >>
> >> -eric
> >>
> >>> Moving forward I would like to see us do a better job on swizzeling
> loads. I think that adding support for reverse loads would be easy to do
> and allow the vectorization of many more patterns.
> >>>
> >>> Thanks,
> >>> Nadav
> >>>
> >>>> Is
> >>>> there some other approach you'd like to get optimizations like this?
> >>>>
> >>>> -eric
> >>>>
> >>>> http://reviews.llvm.org/D3800
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> llvm-commits mailing list
> >>> llvm-commits at cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140520/ae0532fd/attachment.html>