[PATCH] D70107: [VFABI] TargetLibraryInfo mappings in IR.

[Anna Thomas via Phabricator via llvm-commits]

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