Dune Core Modules (2.9.0)
|SIMD abstractions for Vc. |
This implements the vectorization interface for Vc types, namely
As an application developer, you need to
#include <dune/common/simd/vc.hh>. You need to make sure that
HAVE_VC is true before doing so:
- If your program works both in the presence and the absence of Vc, wrap the include in
- If you write a unit test, in your
dune_add_test(... CMAKE_GUARD Vc_FOUND)
You also need to make sure that the compiler uses the correct flags and that the linker can find the library. (The compilation flags include one that ensures a name mangling scheme that can distinguish the compiler-intrinsic vector types from non-vector types is used.)
- Either use
- or use
dune_enable_all_packages()in your module's toplevel
There should be no need to explicitly call
find_package(Vc) in your
CMakeLists.txt, dune-common already does that. If your module can't live without Vc, you may however want to do something like this in your
If you just want to compile dune, and have Vc installed to a location where cmake is not looking by default, you need to add that location to
CMAKE_PREFIX_PATH. E.g. pass
-DCMAKE_PREFIX_PATH=$VCDIR to cmake, for instance by including that in the variable
CMAKE_FLAGS in the options file that you pass to dunecontrol.
$VCDIR should be the same directory that you passed in
-DCMAKE_INSTALL_PREFIX=... to cmake when you compiled Vc, i.e. Vc's main include file should be found under
$VCDIR/include/Vc/Vc, and the library under
$VCDIR/lib/libVc.a or similar.
During thorough testing of the Vc abstraction implementation it turned out that certain operations were not supported, or were buggy. This meant that the tests had to be relaxed, and/or some restrictions had to made as to how things must be done through the SIMD abstraction, see Limitations of the Abstraction Layer.
For future reference, here is a detailed list of things that certain Vc types do or don't support.
s denotes a scalar object/expression (i.e. of type
double or in the case of masks
v denotes a vector/mask object/expression.
sv means that both scalar and vector arguments are accepted.
V denotes a vector/mask type.
@ means any applicable operator that is not otherwise listed.
-  The result of the mask-mask
!=operation is a scalar.
++(either kind) on bools is deprecated by the standard
-  contrary to the other operators, the expected result for
(sv1, sv2)is exactly
sv2, no broadcasting applied.
-  Checked with
SimdArray<int, 4>::Mask, which behaved identical
y: operation generally works; some instances of the operation may not apply
*N*: operation generally does not work; some instances of the operation may not apply
n/a: operation does not apply (i.e. bitwise operations to floating-point operands,
--(and in the future possibly
++) to boolean operands, assignment operators to scalar left hand sides)
Each operation was tested with the full set of combinations of possible
const lvalue/xvalue arguments. Each combination of constness and value category was applied to the scalar type and the operation tried in an SFINAE context; combinations that failed here were skipped for vector arguments too.