Name Description Size
arm
check.h 9847
debug-trap.h !defined(SIMDE_DEBUG_TRAP_H) 3120
hedley.h 77513
mips
simde-align.h I know this seems a little silly, but some non-hosted compilers don't have stddef.h, so we try to accomodate them. 18009
simde-arch.h Alpha <https://en.wikipedia.org/wiki/DEC_Alpha> 18257
simde-common.h In some situations, SIMDe has to make large performance sacrifices for small increases in how faithfully it reproduces an API, but only a relatively small number of users will actually need the API to be completely accurate. The SIMDE_FAST_* options can be used to disable these trade-offs. They can be enabled by passing -DSIMDE_FAST_MATH to the compiler, or the individual defines (e.g., -DSIMDE_FAST_NANS) if you only want to enable some optimizations. Using -ffast-math and/or -ffinite-math-only will also enable the relevant options. If you don't want that you can pass -DSIMDE_NO_FAST_* to disable them. 42440
simde-complex.h Support for complex math. We try to avoid inculding <complex> (in C++ mode) since it pulls in a *lot* of code. Unfortunately this only works for GNU modes (i.e., -std=gnu++14 not -std=c++14) unless you pass -fext-numeric-literals, but there is no way (AFAICT) to detect that flag so we have to rely on __STRICT_ANSI__ to instead detect GNU mode. This header is separate from simde-math.h since there is a good chance it will pull in <complex>, and most of the time we don't need complex math (on x86 only SVML uses it). 5257
simde-constify.h Constify macros. For internal use only. These are used to make it possible to call a function which takes an Integer Constant Expression (ICE) using a compile time constant. Technically it would also be possible to use a value not trivially known by the compiler, but there would be a siginficant performance hit (a switch switch is used). The basic idea is pretty simple; we just emit a do while loop which contains a switch with a case for every possible value of the constant. As long as the value you pass to the function in constant, pretty much any copmiler shouldn't have a problem generating exactly the same code as if you had used an ICE. This is intended to be used in the SIMDe implementations of functions the compilers require to be an ICE, but the other benefit is that if we also disable the warnings from SIMDE_REQUIRE_CONSTANT_RANGE we can actually just allow the tests to use non-ICE parameters 18585
simde-detect-clang.h This file was originally part of SIMDe (<https://github.com/simd-everywhere/simde>). You're free to do with it as you please, but I do have a few small requests: * If you make improvements, please submit them back to SIMDe (at <https://github.com/simd-everywhere/simde/issues>) so others can benefit from them. * Please keep a link to SIMDe intact so people know where to submit improvements. * If you expose it publicly, please change the SIMDE_ prefix to something specific to your project. The version numbers clang exposes (in the ___clang_major__, __clang_minor__, and __clang_patchlevel__ macros) are unreliable. Vendors such as Apple will define these values to their version numbers; for example, "Apple Clang 4.0" is really clang 3.1, but __clang_major__ and __clang_minor__ are defined to 4 and 0 respectively, instead of 3 and 1. The solution is *usually* to use clang's feature detection macros (<https://clang.llvm.org/docs/LanguageExtensions.html#feature-checking-macros>) to determine if the feature you're interested in is available. This generally works well, and it should probably be the first thing you try. Unfortunately, it's not possible to check for everything. In particular, compiler bugs. This file just uses the feature checking macros to detect features added in specific versions of clang to identify which version of clang the compiler is based on. Right now it only goes back to 3.6, but I'm happy to accept patches to go back further. And, of course, newer versions are welcome if they're not already present, and if you find a way to detect a point release that would be great, too! 5962
simde-diagnostic.h SIMDe targets a very wide range of standards and compilers, and our goal is to compile cleanly even with extremely aggressive warnings (i.e., -Weverything in clang, -Wextra in GCC, /W4 for MSVC, etc.) treated as errors. While our preference is to resolve the underlying issue a given diagnostic is warning us about, sometimes that's not possible. Fixing a warning in one compiler may cause problems in another. Sometimes a warning doesn't really apply to us (false positives), and sometimes adhering to a warning would mean dropping a feature we *know* the compiler supports since we have tested specifically for the compiler or feature. When practical, warnings are only disabled for specific code. For a list of warnings which are enabled by default in all SIMDe code, see SIMDE_DISABLE_UNWANTED_DIAGNOSTICS. Note that we restore the warning stack when SIMDe is done parsing, so code which includes SIMDe is not deprived of these warnings. 21064
simde-f16.h Portable version which should work on pretty much any compiler. Obviously you can't rely on compiler support for things like conversion to/from 32-bit floats, so make sure you always use the functions and macros in this file! The portable implementations are (heavily) based on CC0 code by Fabian Giesen: <https://gist.github.com/rygorous/2156668> (see also <https://fgiesen.wordpress.com/2012/03/28/half-to-float-done-quic/>). I have basically just modified it to get rid of some UB (lots of aliasing, right shifting a negative value), use fixed-width types, and work in C. 9284
simde-features.h simde-arch.h is used to determine which features are available according to the compiler. However, we want to make it possible to forcibly enable or disable APIs 25610
simde-math.h Attempt to find math functions. Functions may be in <cmath>, <math.h>, compiler built-ins/intrinsics, or platform/architecture specific headers. In some cases, especially those not built in to libm, we may need to define our own implementations. 59470
wasm
x86