<div dir="ltr">Hi Hal,<div><br></div><div>I can see the advantage of both approaches. Metadata, as you say, allows pragmas and frontends to pass information to the LoopVectorizer without target specific overrides (creating a new Target{Library,Transform}Info). Hooks in Target{L,T}Info allow greater control and greater complexity in choosing vectorized versions.</div>
<div><br></div><div>Fundamentally I think the two approaches aren't compatible, so one needs to be chosen as the preferred route. I actually don't mind which - to me it looks like Hal and Renato prefer metadata, and Nadav and Arnold prefer hooks, but I may have misinterpreted responses.</div>
<div><br></div><div>Cheers,</div><div><br></div><div>James</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 16 December 2013 20:59, 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>
> 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 the loop vectorizer<br>
><br>
><br>
</div><div><div class="h5">> On Dec 16, 2013, at 11:08 AM, James Molloy <<a href="mailto:James.Molloy@arm.com">James.Molloy@arm.com</a>><br>
> wrote:<br>
><br>
> > Hi Renato, Nadav,<br>
> ><br>
> > Attached is a proof of concept[1] patch for adding the ability 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 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 a<br>
> > set of hooks that allow the LoopVectorizer to interrogate its<br>
> > client as to whether calls are vectorizable and if so, how. Renato<br>
> > argued that this was suboptimal as it required a client to invoke<br>
> > the LoopVectorizer manually and couldn’t be tested through opt. 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 “target<br>
> triple = x86_64-gnu-linux-with_opencl_vector_lib") in the .ll 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 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>
</div></div>We don't have a good model currently for non-intrinsic function calls. Once we do, we'll want to know how expensive the vectorized versions are compared to the scalar version. Short of that, I think that a reasonable approximation is that any function calls will be the most expensive things in a loop, and the ability to vectorize them will be the most important factor in determining the vectorization factor.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Hal<br>
</font></span><div class="im HOEnZb"><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>
</div><div class="im HOEnZb">--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br></div>