<div dir="ltr">This generally sounds good to me too - my only slight niggle is as TargetLibraryInfo is an ImmutablePass, it is always run first in a PassManager, so the LoopVectorizer won't see metadata that some user/frontend pass in the same PassManager has added.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On 16 December 2013 21:34, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">----- Original Message -----<br>
> From: "Arnold Schwaighofer" <<a href="mailto:aschwaighofer@apple.com">aschwaighofer@apple.com</a>><br>
</div><div class="im">> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>
> Cc: "James Molloy" <<a href="mailto:james@jamesmolloy.co.uk">james@jamesmolloy.co.uk</a>>, "llvm-commits" <<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>><br>
> Sent: Monday, December 16, 2013 3:32:03 PM<br>
> Subject: Re: RFC: Enable vectorization of call instructions in the loop vectorizer<br>
><br>
><br>
</div><div class="im">> On Dec 16, 2013, at 3:14 PM, Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br>
><br>
> > ----- Original Message -----<br>
</div><div class="im">> >> From: "James Molloy" <<a href="mailto:james@jamesmolloy.co.uk">james@jamesmolloy.co.uk</a>><br>
> >> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>
> >> Cc: "Arnold Schwaighofer" <<a href="mailto:aschwaighofer@apple.com">aschwaighofer@apple.com</a>>,<br>
> >> "llvm-commits" <<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>><br>
> >> Sent: Monday, December 16, 2013 3:05:26 PM<br>
> >> Subject: Re: RFC: Enable vectorization of call instructions in the<br>
> >> loop vectorizer<br>
> >><br>
> >><br>
> >> Hi Hal,<br>
> >><br>
> >><br>
> >> I can see the advantage of both approaches. Metadata, as you say,<br>
> >> allows pragmas and frontends to pass information to the<br>
> >> LoopVectorizer without target specific overrides (creating a new<br>
> >> Target{Library,Transform}Info). Hooks in Target{L,T}Info allow<br>
> >> greater control and greater complexity in choosing vectorized<br>
> >> versions.<br>
> >><br>
> >><br>
> >> Fundamentally I think the two approaches aren't compatible, so one<br>
> >> needs to be chosen as the preferred route.<br>
> ><br>
> > I think they are compatible, and we should have both. All we need<br>
> > is some function that forms the list of alternatives that first<br>
> > checks metadata, and then adds any alternatives provided by<br>
> > TLibInfo. Why would this not work?<br>
><br>
><br>
</div>> I don’t think we need two interfaces (TargetLibInfo and meta data on<br>
> the call site) for this. I see no reason why TargetLibraryInfo could<br>
> not be initialized with metadata from the Module? If we can do this<br>
> then we don’t need metadata on the function call and have an unified<br>
> interface.<br>
<br>
That also sounds good to me.<br>
<br>
 -Hal<br>
<br>
><br>
> Best,<br>
> Arnold<br>
<div class="HOEnZb"><div class="h5">><br>
><br>
> ><br>
> > -Hal<br>
> ><br>
> >> I actually don't mind<br>
> >> which - to me it looks like Hal and Renato prefer metadata, and<br>
> >> Nadav and Arnold prefer hooks, but I may have misinterpreted<br>
> >> responses.<br>
> >><br>
> >><br>
> >> Cheers,<br>
> >><br>
> >><br>
> >> James<br>
> >><br>
> >><br>
> >><br>
> >> On 16 December 2013 20:59, Hal Finkel < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> > wrote:<br>
> >><br>
> >><br>
> >><br>
> >> ----- Original Message -----<br>
> >>> From: "Arnold Schwaighofer" < <a href="mailto:aschwaighofer@apple.com">aschwaighofer@apple.com</a> ><br>
> >>> To: "James Molloy" < <a href="mailto:James.Molloy@arm.com">James.Molloy@arm.com</a> ><br>
> >>> Cc: "llvm-commits" < <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a> ><br>
> >>> Sent: Monday, December 16, 2013 12:03:02 PM<br>
> >>> Subject: Re: RFC: Enable vectorization of call instructions in<br>
> >>> the<br>
> >>> loop vectorizer<br>
> >>><br>
> >>><br>
> >><br>
> >><br>
> >>> On Dec 16, 2013, at 11:08 AM, James Molloy < <a href="mailto:James.Molloy@arm.com">James.Molloy@arm.com</a><br>
> >>> ><br>
> >>> wrote:<br>
> >>><br>
> >>>> Hi Renato, Nadav,<br>
> >>>><br>
> >>>> Attached is a proof of concept[1] patch for adding the ability<br>
> >>>> to<br>
> >>>> vectorize calls. The intended use case for this is in domain<br>
> >>>> specific languages such as OpenCL where tuned implementation of<br>
> >>>> functions for differing vector widths exist and can be<br>
> >>>> guaranteed<br>
> >>>> to be semantically the same as the scalar version.<br>
> >>>><br>
> >>>> I’ve considered two approaches to this. The first was to create<br>
> >>>> a<br>
> >>>> set of hooks that allow the LoopVectorizer to interrogate its<br>
> >>>> client as to whether calls are vectorizable and if so, how.<br>
> >>>> Renato<br>
> >>>> argued that this was suboptimal as it required a client to<br>
> >>>> invoke<br>
> >>>> the LoopVectorizer manually and couldn’t be tested through opt.<br>
> >>>> I<br>
> >>>> agree.<br>
> >>><br>
> >>> I don’t understand this argument.<br>
> >>><br>
> >>> We could extend target library info with additional api calls to<br>
> >>> query whether a function is vectorizable at a vector factor.<br>
> >>> This can be tested by providing the target triple string (e.g<br>
> >>> “target<br>
> >>> triple = x86_64-gnu-linux-with_opencl_vector_lib") in the .ll<br>
> >>> file<br>
> >>> that informs the optimizer that a set of vector library calls is<br>
> >>> available.<br>
> >>><br>
> >>> The patch seems to restrict legal vector widths dependent on<br>
> >>> available vectorizable function calls. I don’t think this should<br>
> >>> work like this.<br>
> >>> I believe, there should be an api on TargetTransformInfo for<br>
> >>> library<br>
> >>> function calls. The vectorizer chooses the cheapest of either an<br>
> >>> intrinsic call or a library function call.<br>
> >>> The overall cost model determines which VF will be chosen.<br>
> >><br>
> >> We don't have a good model currently for non-intrinsic function<br>
> >> calls. Once we do, we'll want to know how expensive the vectorized<br>
> >> versions are compared to the scalar version. Short of that, I<br>
> >> think<br>
> >> that a reasonable approximation is that any function calls will be<br>
> >> the most expensive things in a loop, and the ability to vectorize<br>
> >> them will be the most important factor in determining the<br>
> >> vectorization factor.<br>
> >><br>
> >> -Hal<br>
> >><br>
> >><br>
> >>><br>
> >>> Thanks,<br>
> >>> Arnold<br>
> >>><br>
> >>><br>
> >>> _______________________________________________<br>
> >>> llvm-commits mailing list<br>
> >>> <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
> >>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
> >>><br>
> >><br>
> >><br>
> >> --<br>
> >> Hal Finkel<br>
> >> Assistant Computational Scientist<br>
> >> Leadership Computing Facility<br>
> >> Argonne National Laboratory<br>
> >><br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> llvm-commits mailing list<br>
> >> <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
> >> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
> >><br>
> >><br>
> ><br>
> > --<br>
> > Hal Finkel<br>
> > Assistant Computational Scientist<br>
> > Leadership Computing Facility<br>
> > Argonne National Laboratory<br>
><br>
><br>
<br>
--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</div></div></blockquote></div><br></div>