[llvm-dev] [RFC] Re-implementing -fveclib with OpenMP

[Renato Golin via llvm-dev]

Hi Francesco,

This is a huge RFC and I don't think we can discuss all of it at the
same time, at least not in a constructive manner.

What ends up happening is that people ignore the thread and developers
get upset.

So, I'll start with the summary, to make sure the overall assumptions
in the RFC match the ones I have about it, then we can delve into
details.

I also think we should not discuss user-include files now. Whatever we
define for the standard ones will work for user driven ones, but user
driven have additional complexities that will only get in the way of
the standard discussion.

Comments inline...

On Wed, 12 Dec 2018 at 03:47, Francesco Petrogalli via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Summary
> =======
>
> New `veclib` directives in clang

I know this is not new but, why "fveclib"? From the review, I take
this is the same as GCC's "mveclibabi", and if it is, why come up with
a new name for the same thing?

If it's not, what justifies implementing a different way of handling
the same concept (vector math libraries), which is surely going to
confuse a lot of users.

In some reviews, it was said that some proprietary compilers already
use "fveclib", but between being coherent with other OSS compilers and
closed source compilers, I think the answer is clear.

I'm not against the name, I'm just making sure we're not creating
problem for ourselves.


> --------------------------------
>
> 1.  `#pragma veclib declare simd [clause, ]`, same as
>     `#pragma omp declare simd` from OpenMP 4.0+.

Why not just use "pragma omp simd"?

If I recall correctly, there's an option to allow OMP SIMD pragmas
without enabling full OMP, so that we can use it without needing all
the headers and libraries, just to control vectorisation.

Creating new pragmas should be seen with extreme prejudice, as these
things tend to simplify the life of the compiler developers but create
nightmares for application developers, especially if they want to use
multiple compilers.


> 2.  `#pragma omp declare variant`, same as `#pragma omp declare variant`
>     restricted to the `simd` context selector, from OpenMP 5.0+.

Is this just for the user-driven stuff? If so, let's look at it later.


> New `math.h` header file
> ------------------------
>
> Shipped in `<clang>/lib/Headers/math.h`, contains all the declaration of
> the functions available in the vector library `X`, `ifdef` guarded by
> the macro `__CLANG_ENABLE_LIBRARY_X`.

So, the compiler will have the header files and the libraries will be
in charge of implementing them, to avoid linkage errors?

If this is a standard ABI that multiple libraries follow, I'm in
favour. If we'll end up with one (or more) header(s) per library or
worse, need to update the header every time the library changes
something, then I'm completely against.

The latter will generate the compatibility issue I mentioned in one of
the reviews, where the compiler has different header files but the
implementations are slightly off-base. Keeping multiple copies of
those libraries in the same file system (for different users in the
same clusters) is even worse.

That's the kind of thing that is better left for the libraries
themselves. If they have both headers and objects, keeping all
together into one directory is enough.


> Option behavior, and interaction with OpenMP
> --------------------------------------------
>
> `-fveclib=X`
>
> :   The driver transform this into
>     `-fparse-veclib -D__CLANG_ENABLE_LIBRARY_X=1 -lX`. This is used only
>     for users that want to vectorize `math.h` functions.

Why not just include the header when you use it, instead of include
and guard for all cases?

> `-fopenmp[-simd]`
>
> :   No vectorization happens other then for those functions that are
>     marked with OpenMP declare simd. The header `math.h` is loaded, but
>     the `veclib` decorated declarations are invisible to the compiler
>     instance because hidden behind the `__CLANG_ENABLE_LIBRARY_X`
>     macros, which are not defined.

"No vectorisation" you mean, no "function" vectorisation. Other
vectorisation (from -O3 etc) will still happen.

> `-fopenmp[-simd] -fveclib=X` or
>
> : Same behavior as without the `-fopenmp[-simd]` option.

So, fveclib will enable OMP SIMD by default? I think that's what some
of the reviews (particularly on certification) were against. This is
not correct.

The only way this can work is without including OMP dependencies when
using vector libraries. If the omp-simd option does not add OMP deps
(as I hinted above, there may be a way), then this is fine. But if
veclib flags force OMP dependencies, than this cannot work.

-- 
cheers,
--renato