[llvm-dev] [RFC] Re-implementing -fveclib with OpenMP (original) (raw)

Renato Golin via llvm-dev llvm-dev at lists.llvm.org
Fri Dec 14 15:40:51 PST 2018

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:

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

More information about the llvm-dev mailing list