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

[Renato Golin via llvm-dev]

On Fri, 14 Dec 2018 at 17:05, Francesco Petrogalli
<Francesco.Petrogalli at arm.com> wrote:
> Although I see your reasoning around the compatibility with other compilers, I don’t this this is the place to discuss this. The -fveclib option was introduced prior to this RFC, and for now we have to leave with it. Whether we want to keep it or change it to a gcc compatible one, is not something we have to discuss here. In particular, I suspect that there are users of -fveclib that would shout in the mailing list  is we convert it to a new option, as it will break their build system. Again, not for this RFC discussion.

I'm trying to avoid the proliferation of something that may have
passed in unnoticed.

So, if there is no special reason to be called 'fveclib' I strongly
suggest we move it to 'mvelibabi' sooner rather than later.

While this is not relevant to this RFC in particular, it's a relevant
subject that needs to be raised. It's not uncommon that people choose
names that are familiar to them without considering the wider
ecosystem. I'm just making sure we do.


> Yes, the idea was to use OpenMP pragmas only. From the discussion it turned out that OpenMP vectorization and function vectorization are two orthogonal problems (in the sense that we want to be able to turn on math function vectorization without enabling vectorization of the functions that users may mark as declare simd, and vice versa), so we decided to introduce something new (the veclib pragma). It is 100% compatible with the OpenMP one, so it minimizes the work needed in the compiler to support it, and at the same time it is based on a public standard, so I think it is the best choice we could do.

I see. While doing so would simplify a new implementation, it would
also add yet another set of pragmas that are rarely used, while there
are already existing pragmas that do a similar job.

More importantly, if we try to cater to every possible scenario, the
maintenance in the compiler will increase considerably, and I'm
worried that this is already the case in a multitude of issues around
this RFC.

I want to avoid confusing the users, which will happen if:
 - We implement more than we need in an attempt to mimic openmp-simd
for a simpler issue
 - We use different flags than other compilers for no strong reason
 - We create more and more pragmas that will have different impact,
regardless of their semantics

> The section on the compatibility with OpenMP explain how -fopenmp-[simd] and -fveclib interacts.

That section says the behaviour of 0fveclib is the same with or
without -fopenmp-simd, which is confusing, because I would imagine the
additional flag would enable other simd optimisations that just
fveclib wouldn't.

> No - this is needed to be able to attach non standard names to the standard ones (see the example of the vector-variant attribute for SVML).

I'm not sure I understand what non-standard names are, then.

> The compiler doesn’t have control on the library

Exactly my point

> the behavior you are describing will always happen.

Which one?

> The only advantage of storing in a header file with standard descriptor (the openmp based ones) is that it makes it easier to maintain and modify.

Easier for whom? We're talking about two completely separate
communities. Making it easier for one by making it harder for others
won't work.

> The different sets are guarded by preprocessor macros, it could be done also with macros that are specific to version of the libraries.

Now you're passing even more external library knowledge into the
compiler and that's not going to fly.

> The alternative is to require that the libraries are shipped with a header file with the descriptors of the vector version (OpnMP would be the best choice, because it is standard). Unfortunately, I don't think this is something that is going to happen (but I would be very happy to be proved wrong here!)

If the headers describe the library implementation, especially if it
has different implementation for different versions, then it _must_ be
in the library. Keeping that in the compiler is just wrong.

> We have to store the list of the available vector functions somewhere. Now it is done in the backend of LLVM, this RFC proposes to move it to the frontend, in a convenient way that will enable more vectorization opportunities by being compatible with what OpenMP provides.

To me, neither the back-end nor the front-end are good alternatives.
The back-end has them because they're standard (is this the libmvec
ones?), but if we want to emit external library calls, which can
change without the compiler knowledge, then this _has_ to be outside
of the compiler, in a header file that is controlled by the library.

How to find the alternatives would be a matter of having an ABI that
encodes that (like Intel's and Arm's) and making sure the libraries
provide those. Just like any old C library.

Further specialised (non-standard?) functions would need pragma
support, and AFAIK, OpenMP supports that, so re-implementing in
another way just because a few users would benefit is causing a big
cost to a lot of people for the benefit of a few.

In such cases, I usually recommend the few to swallow the cost by
changing their source codes to force specialisation.

> Hum - I am not sure I understand what you re saying here. The idea is to keep user code as it is, with just #include <math.h>. If we come up with a set of library-specific header files shipped with the compiler, we we would have to -include them at command line, so that -fveclib=X would become -lX -include=path/to/X.h

Yes, add the includes in the front-end command line so the user
doesn't have to, but don't call it <math.h>, or that'd create problems
in debuggability and "least surprise" as in "where did this math.h
came from anyway?".

If you do that, then there's no need for macros, as well as making it
easier for libraries to provide headers in default locations. So, the
compiler adds /default/include/folder/library_name_abi.h and the
library package is responsible for providing that header in that
place, so that both clang and gcc can use the same header (if they
want).

> No, I think you got this wrong. -fveclib itself doesn't enable any OpenMP. OpenMP is enabled only when -fopenmp[-simd] is invoked.

Ok.

> :   Same behavior as without the ``-fopenmp[-simd]`` option. In particular, both the "veclib" functions in math.h (or those in the user provided functions when -fveclib-include is used ) are available for vectorization, together with those marked by the OpenMP pragmas.

That's why I thought this would enable OpenMP, which is why it's
confusing. If -fopenmp-simd doesn't enable OpenMP, then why create a
veclib pragma in the first place, instead of using omp simd with
-fopenmp-simd?

-- 
cheers,
--renato