llvm dev - Dec 2016 - [RFC] Enable "#pragma omp declare simd" in the LoopVectorizer

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.

On 12 December 2016 at 16:49, Francesco Petrogalli
<Francesco.Petrogalli at arm.com> wrote:
> 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.
The information needs to be serialised into IR, so that a multi-step
compilation (clang->llc) picks up the details. Otherwise, we'd be
vectorising when coming from Clang and not when passing through
opt/llc.

Admittedly, opt/llc are not user tools, but we should try to not have
any hidden knowledge that can't be inferred again by the debug tools
(or testing becomes impossible).

So, you either add metadata, attributes or you create multiple weak
global functions that get destroyed by the linker if unused.

Makes sense?

cheers,
--renato

----- Original Message -----
> From: "Renato Golin via llvm-dev" <llvm-dev at
lists.llvm.org>
> To: "Francesco Petrogalli" <Francesco.Petrogalli at
arm.com>
> Cc: "a bataev" <a.bataev at hotmail.com>, llvm-dev at
lists.llvm.org, "Matt Masten" <matt.masten at intel.com>,
"nd"
> <nd at arm.com>
> Sent: Monday, December 12, 2016 11:05:46 AM
> Subject: Re: [llvm-dev] [RFC] Enable "#pragma omp declare simd"
in the	LoopVectorizer
> 
> On 12 December 2016 at 16:49, Francesco Petrogalli
> <Francesco.Petrogalli at arm.com> wrote:
> > 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.
> 
> The information needs to be serialised into IR, so that a multi-step
> compilation (clang->llc) picks up the details. Otherwise, we'd be
> vectorising when coming from Clang and not when passing through
> opt/llc.
FWIW, this is the situation we have now with function vectorization (both Clang
and opt end up calling TLI->addVectorizableFunctionsFromVecLib based on
command-line arguments, etc.). We probably should move this into some function
attribute.

 -Hal 
> 
> Admittedly, opt/llc are not user tools, but we should try to not have
> any hidden knowledge that can't be inferred again by the debug tools
> (or testing becomes impossible).
> 
> So, you either add metadata, attributes or you create multiple weak
> global functions that get destroyed by the linker if unused.
> 
> Makes sense?
> 
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory