Comments (16)
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.
from sleef.
What do you exactly mean by LLVM compatibility?
from sleef.
SLEEF will export functions with names that are used in LLVM.
from sleef.
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.
from sleef.
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.
from sleef.
Why do you think that having libsleef
and glibc
exposing the same names is a problem?
from sleef.
Is there a way for the compiler to choose which library to use?
from sleef.
Yes, -lm
links agains libm
in glibc
. -lsleef
will link into libsleef
.
from sleef.
Ahh, but then sleef has to expose the non-vectorized math functions in the other names.
from sleef.
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.
from sleef.
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...
-
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.
-
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.
-
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).
from sleef.
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.
from sleef.
A few more requirements :
- Cross compilation
- Building static library with MSVC
from sleef.
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:
- 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. - 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
theENABLE_
-like macro. Please bear with me, I will create this
issue as soon as possible. - Build and run the tests with the
cmake
-producedlibsleef.so
and
libsleefsimd.so
. No SLEEF source code should be compiled here,
just the tester files to be linked againstlibsleef.so
and
libsleefsimd.so
. I will create a specific issue also for building
and running the current tests withcmake
.
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
from sleef.
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.
from sleef.
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.
from sleef.
Related Issues (20)
- Failures on various archs for gcc 12 HOT 2
- Failures for s390x VXE2 with qemu HOT 2
- Some tests fail on AArch64 with LLVM 17 HOT 1
- Deprecated usage of MD5 API
- Fix RVV inline header generation HOT 3
- Test more OS-es in Github Actions HOT 7
- Add GNU make as potential generator in CI
- Please, create tag release HOT 3
- dft test gets stuck during initialisation when hardware vector length is very long HOT 2
- Failure on ppc64 when cross compiled with gcc-11 toolchain
- Inaccuracy for f32 erf on non-FMA instruction set
- New test failures in 3.6 HOT 7
- F64 exp returns infinity slightly too soon
- RISC-V architecture missing on https://sleef.org/ HOT 1
- Clang on Windows and GNU ABI
- RISC-V: exploit `-mrvv-vector-bits=zvl` when used HOT 1
- Missing unversioned symbolic link for GNUABI version in 3.6 HOT 3
- A few API functions were (accidentally?) removed in 3.6 HOT 11
- Integrate ARM-software/optimized-routines into sleef? HOT 2
- Improve portability of libm and quad testers
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sleef.