[llvm-dev] LLVM 11 and trunk selecting 4 wide instead of 8 wide loop vectorization for AVX-enabled target

[Florian Hahn via llvm-dev]

> On 16 Jul 2020, at 19:54, Neil Henning via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> So for us we use SLEEF to actually implement the libcalls (LLVM intrinsics) that LLVM by default would generate - and since SLEEF has highly optimal 8-wide pow, optimized for AVX and AVX2, we really want to use that.

Right, the way vector versions of library functions are accessed by the vectoriser has changed since the last release. I think the initial patch was https://reviews.llvm.org/D70107 <https://reviews.llvm.org/D70107>.

Vector functions now must be annotated with a vector-function-abi-variant function attribute. There’s the -inject-tli-mappings pass, that is supposed to add the attributes for vector functions from TLI. It seems like this is currently not happening for your custom TLI mappings for some reason.

For example, the Accelerate library has a vector version of log10. Running `opt -vector-library=Accelerate -inject-tli-mappings` on the IR below will add the following attribute to the llvm.log10 call-site, indicating that there’s a <4 x float> version of log10 called vlog10f.

{ "vector-function-abi-variant"="_ZGV_LLVM_N4v_llvm.log10.f32(vlog10f)" }


To double-check, if running -inject-tli-mappings on your example does not add the vector-function-abi-variant attribute for `pow`, the vectorisers won’t know about them. If the vector-function-abi-variant attribute is actually created, but the vector version is not used nonetheless, it would be great if you could share the IR with the attributes, as they depend on the downstream TLI.

I am also CC’ing Francesco, who might be able to help you pinning down where exactly things go wrong with the mapping.

Cheers,
Florian

——

define float @call_llvm.log10.f32(float %in) {
  %call = tail call float @llvm.log10.f32(float %in)
  ret float %call
}

declare float @llvm.log10.f32(float)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200717/adc19c3d/attachment.html>