llvm dev - May 2019 - [cfe-dev] [RFC] Expose user provided vector function for auto-vectorization.

On Fri, 31 May 2019 at 17:19, Francesco Petrogalli via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> TOPIC 2: metadata vs attribute
>
> Also, @Renato expressed concern that metadata might be dropped by
optimization passes - would using attributes prevent that?
I think it would, thanks!

> TOPIC 3: "there are no special arguments / flags / status regs that
are used / changed in the vector version that the compiler will have to
"just know”
>
> I believe that this concern is raised by the problem of handling FP
exceptions? If that’s the case, the compiler is not allowed to do any assumption
on the vector function about that, and treat it with the same knowledge of any
other function, depending on the visibility it has in the compilation unit.
@Renato, does this answer your question?
So, if there are side-effects on the scalar version, there will be
also in the vector version? Unfortunately, this does not work in
practice by default (different units have different rules).

If we want to enforce this, it's up to the library implementation to
provide similar behaviour (either hide or create side-effects) and it
will be "library error" if they do not.

This seems a bit heavy handed, though...

--renato

> On May 31, 2019, at 11:57 AM, Renato Golin <rengolin at gmail.com>
wrote:
> 
> On Fri, 31 May 2019 at 17:19, Francesco Petrogalli via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> TOPIC 2: metadata vs attribute
>> 
>> Also, @Renato expressed concern that metadata might be dropped by
optimization passes - would using attributes prevent that?
> 
> I think it would, thanks!
> 
> 
>> TOPIC 3: "there are no special arguments / flags / status regs
that are used / changed in the vector version that the compiler will have to
"just know”
>> 
>> I believe that this concern is raised by the problem of handling FP
exceptions? If that’s the case, the compiler is not allowed to do any assumption
on the vector function about that, and treat it with the same knowledge of any
other function, depending on the visibility it has in the compilation unit.
@Renato, does this answer your question?
> 
> So, if there are side-effects on the scalar version, there will be
> also in the vector version? Unfortunately, this does not work in
> practice by default (different units have different rules).
> 
The OpenMP use of  `declare simd` and `declare variant` informs the compiler
that the underlying scalar function is “safe to vectorize”. I believe that
side-effects are excluded from the list of things that are “safe to vectorize”.

See https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5.0.pdf,
page 118, lines 23-24:

“The execution of the function or subroutine cannot have any side effects that
would alter its execution for concurrent iterations of a SIMD chunk."
> If we want to enforce this, it's up to the library implementation to
> provide similar behaviour (either hide or create side-effects) and it
> will be "library error" if they do not.
> 
> This seems a bit heavy handed, though...
> 
> --renato

On Fri, 31 May 2019 at 18:38, Francesco Petrogalli
<Francesco.Petrogalli at arm.com> wrote:
> “The execution of the function or subroutine cannot have any side effects
that would alter its execution for concurrent iterations of a SIMD chunk."
Right, but this is a clang-based directive, not an OMP one, so we
should extend the same guarantees explicitly. I think following OMP's
restrictions in our own document is the right way to go.

thanks,
--renato