[llvm-dev] [RFC] Enable "#pragma omp declare simd" in the LoopVectorizer
Francesco Petrogalli via llvm-dev
llvm-dev at lists.llvm.org
Mon Dec 12 08:49:52 PST 2016
Xinmin,
Allow me to share a couple of comments about what Renato is saying.
On 08/12/2016 22:08, "Renato Golin" <renato.golin at linaro.org> wrote:
>I'm still unsure how the simplistic mangling we have today will work
>around the multiple versions we could have with NEON (and in the
>future, SVE) without polluting the mangling quite a lot (have you seen
>arm_neon.h?).
Reconstructing the vector parameter types from the name mangling works for
fixed-width vector architectures, including NEON.
For SVE, the alternative method I am proposing of using IR types will make
easier the handling of width agnostic
vector function types.
With SVE in we could have multiple version of the same function for
different vector lengths, plus a totally width agnostic version that would
work on any SVE implementation. All these information could be potentially
used
by the compiler, I see an advantage in having them encoded in IR
structures (FunctionType and VectorType) instead of strings, as is would
make the information directly accessible by other parts of the compiler.
There is a proposal in the ML for extending the IR vector type to support
width agnostic
vectors. Whatever will be the final shape of such vectors, I suspect it
would be easier to handle multiple width agnostic version of functions by
classifying them with IR types.
>
>So, we may get away with it for now with some basic support and the
>current style, but this should grow into a more flexible scheme.
>
>About the current IR form, I don't particularly like how they're tied
>up together, but other than having multiple global functions defined
>(something like weak linkage?), I don't have a better idea right now.
I am not sure I understand here. In my patch, all I am doing is “vector
symbol awareness generation”. There are no globals that are generated in
the final object file, it is just the TargetLibraryInfoImpl that is being
populated with the info needed by the vectorizer.
More information about the llvm-dev
mailing list