Migration to cmake and llvm compatibility

[shibatch]

As we all know, the current build scheme with makefile is a little messy. I recently tried to learn how to use cmake, and I think it is now possible to begin migration. The new scheme should make it easier for llvm to adopt the latest version of SLEEF. I committed (kind of) llvm-compatibility support already, but it is just renaming of the functions. I think it is better to talk about how we design these features.

[shibatch]

The requirements would be like following:

• Integration with llvm should be easier.

• It should support Linux, Windows(MSVC and Cygwin) and Mac OSX.

• It should support x86, aarch64 and aarch32.

• It should support GCC, Clang, Intel Compiler and MSVC.

• It should detect compiler features automatically.

• New testing tool?

• New benchmarking tool?

As for integration with llvm, I am considering something like just putting the whole source tree of SLEEF at some specific place in the llvm source tree, and cmake will take care of everything.

[fpetrogalli]

What do you exactly mean by LLVM compatibility?

[shibatch]

SLEEF will export functions with names that are used in LLVM.

[fpetrogalli]

I see, that's nothing to do with cmake and the build system. Let's keep it separate. Having cmake instead of handcrafted makefiles will not make exporting LLVM names any easier. Also, as far as I know LLVM does not have any of these names there at the moment, so I think it is better to wait until LLVM will have decided the names.

In my opinion it would be better to expose the functions to any compiler by exporting the vector ABI defined names. This makes the library available not just to one compiler but to all compilers that comply to the vector ABI. We have already exported those symbols (the _ZGV ones).

Now, as for cmake, I agree with you with the following requirements:

• support Linux, Windows (MSVC and Cygwin) and Mac OSX
• support x86, aarch64 and aarch32
• It should support GCC, Clang, Intel Compiler and MSVC.
• it should detect compiler features automatically

All this should be done incrementally with small patches, adding features one by one until we cover all the functionalities we want to cover. As a starting point we should just use cmake to build the library on x86, targeting all teh vector architectures available in the compiler. The starting compiler should be gcc, as it is available in the travis-CI service.

To answer your questions:

• new testing tool? no, I think we should discuss and implement this separately
• new benchmarking tool? no, same as for the testing tool.

@hfinkel we are interested in hear your thoughts here.

[shibatch]

So, LLVM has not decided the names for functions. The problem with the current vector ABI defined names would be that glibc has the functions with same names.

[fpetrogalli]

Why do you think that having libsleef and glibc exposing the same names is a problem?

[shibatch]

Is there a way for the compiler to choose which library to use?

[fpetrogalli]

Yes, -lm links agains libm in glibc. -lsleef will link into libsleef.

[shibatch]

Ahh, but then sleef has to expose the non-vectorized math functions in the other names.

[fpetrogalli]

Yes - there are multiple ways we could do this. However, I would like to focus this conversation on the cmake development. The names of the functions are irrelevant at this level.

[hfinkel]

I agree that we should split this issue into a couple of different issues. The build system, naming, testing, etc. are all related but separable. That said...

1. Setting up the build system like other LLVM subprojects so that, in addition to building separately, will work "out of the box" by dropping the source into the runtimes subdirectory, will be a nice feature. runtimes/CMakeLists.txt has support for globbing up whatever is in the directory, although I'm not exactly sure how this support works. I also suspect we can add this support after the initial cmake transition.

2. Regarding naming, LLVM has certainly not picked names. I recommend exporting the vector functions using the "standard" vector ABI. Feel free to also export under other names (e.g. __sleef_something). In this regard, aliases are cheap to support, and it is good to provide a way to specifically call this library (in addition to using the standard names). We might add more aliases later, and I think that's fine too. Let's move the naming to a different issue, and we can discuss specific options there.

3. I think it is a good idea to build a library replacing standard libm functions as a separate library from the one providing vector functions. Some vendor libraries I've used have a unified behavior here (i.e. linking to the library providing the vector functions also gives you different scalar libm implementations), and I've found that annoying. Having the scalar versions matching the vector versions is convenient, but they don't need to be in the same library file. Thus, I think that building two or three separate libraries would be best (maybe (scalar vs. vector) or (core vs. libm-replacement vs. vector-abi-provider).

[shibatch]

Thank you for your comment.

For item 1, I will look into LLVM's cmakelists to check if there is possibility to add support for "out of the box" placement of the source int the runtimes subdirectory.

For item 2 and 3, I will create another issue for discussing naming.

[shibatch]

A few more requirements :

• Cross compilation
• Building static library with MSVC

[fpetrogalli]

Dear @shibatch and @hfinkel,

here my thoughts on how to start on porting the build system to cmake. I think we all agree on the fact that this needs to be done incrementally and not as a single transition, to minimize the amount of problems that might raise from such a big transition.

Here how I see the three main steps that we should follow:

1. Build the scalar library libsleef.so file. No big design challenge here. I believe this is just a matter of setting up a basic cmake configuration script that knows where the source file of the scalar code are and build the library.
2. Build the vector library libsleefsimd.so. Here is where we need to think carefully how to implement it. I will create an issue with my specific thoughts about this. Spoiler: I want to keep this part as compatible as possible with the way the current makefile based system is targeting different vector extensions by mean of using the ENABLE_-like macro. Please bear with me, I will create this issue as soon as possible.
3. Build and run the tests with the cmake-produced libsleef.so and libsleefsimd.so. No SLEEF source code should be compiled here, just the tester files to be linked against libsleef.so and libsleefsimd.so. I will create a specific issue also for building and running the current tests with cmake.

We can activate each of these components in Travis-CI as soon as they become available.

I agree with @hfinkel that we can think about the LLVM compatibility layer for the build system (the one that will allow dropping the library directly in LLVM out-of-the-box) once we have parts 1. and 2. done.

I think we can also all agree that 1. is what we need to do first - Diana [1], our intern at ARM, can start work on it straightforward on Monday. Let me and Diana know by Monday if you think that 1. should be designed differently, otherwise we are good to start.

As I said, for 2. and 3. I will create new issues where to discuss this.

Thank you,

Francesco

[1] https://github.com/diaena

[shibatch]

It looks good to me. As for 1., you still need to detect if the compiler supports long double and/or float128. I would like to share the cmakelist.txt which I was experimenting.

https://www.dropbox.com/s/jaqtlhzn1oq7wqt/detection.tgz?dl=0

For the macro, I think it is better to separate ENABLE_X macro and COMPILER_SUPPORTS_X macro.

[blapie]

I'm closing this issue as the cmake migration was completed ages ago (#175). There is an open issue for the naming (#33), most likely can be close too. As for LLVM runtime discussion, I think we are way past that in LLVM, as LLVM now has a way to map to SLEEF symbols if specified by compiler option (-fveclib, https://reviews.llvm.org/D134719).

Please feel free to open a new specific issue if you think it wasn't resolved.