[PATCH] D70107: [VFABI] TargetLibraryInfo mappings in IR.
Anna Thomas via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon May 4 11:15:54 PDT 2020
anna added a comment.
@fpetrogalli I have a high level question - why does this pass require that the function should be from one of the vector libraries (Mass, SMVL etc)? I'd like to piggy-back on the `vector-function-abi-variant` attribute to vectorize a call to a scalar function, once the front-end adds this attribute to the callsite. So, if we have the following code in IR, with a scalar call to a function `trivially.vectorizable.func` with the `vector-function-abi-variant` attribute, we will generate the vector function declarations and then LoopVectorizer/SLPVectorizer would do its thing.
Test IR:
; ModuleID = 'chk.ll'
source_filename = "chk.ll"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
define dso_local double @test(float* %Arr) {
entry:
br label %for.cond
for.cond:
%Sum.0 = phi double [ 0.000000e+00, %entry ], [ %add, %for.inc ]
%i.0 = phi i32 [ 0, %entry ], [ %inc, %for.inc ]
%cmp = icmp slt i32 %i.0, 128
br i1 %cmp, label %for.body, label %for.cond.cleanup
for.cond.cleanup:
br label %for.end
for.body:
%idxprom = sext i32 %i.0 to i64
%arrayidx = getelementptr inbounds float, float* %Arr, i64 %idxprom
%0 = load float, float* %arrayidx, align 4
%conv = fpext float %0 to double
%1 = call fast double @trivially.vectorizable.func(double %conv) #2 <-- CALL OF INTEREST
%add = fadd fast double %Sum.0, %1
br label %for.inc
for.inc:
%inc = add nsw i32 %i.0, 1
br label %for.cond
for.end:
ret double %Sum.0
}
declare double @trivially.vectorizable.func(double) #1
attributes #2 = { "vector-function-abi-variant"="_ZGV_LLVM_N2v_trivially.vectorizable.func(trivially.vectorizable.func.v2)" }
attributes #1 = { nounwind readnone speculatable willreturn }
The way I'm thinking - this pass will add the declaration for the vector function in IR `declare <2 x double> @trivially.vectorizable.func.v2(<2 x double>)`.
I've confirmed that once this is done, LoopVectorizer will vectorize that call, i.e. convert the scalar call to the vector version.
Is there any reason to avoid updating this pass with such a functionality? Basically, I'm trying to use something similar to simd pragma in clang (https://clang.llvm.org/docs/AttributeReference.html#id211), where we can specify any function as vectorizable.
Do we already have such support for front-ends to specify any scalar function as 'vectorizable' in IR? This is the only existing attribute that I see which can be reused for this purpose.
Also, to clarify, this vectorized call is finally lowered before passing to the backend/linker etc. So, you can think of this as I have a handwritten nice vectorized form for "trivially.vectorizable.call", which will be inlined before passing to codegen (so these declarations needn't be kept around after the inlining). The main reason for such a usecase is if we want the "high level function call" remaining in IR form until some late pass, which is just before codegen. It is not to bypass some vectorizer code generation limitation. We have such usecases internally.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D70107/new/
https://reviews.llvm.org/D70107
More information about the llvm-commits
mailing list