add support for vectorization library VC

This branch adds support for the Vc library, which add support for vectorization, including an abstraction for intrisics.

We have been using in EXA-Dune and I belive that the integration of vectorization support into the core-Dune is something Dune in general can benefit from. A separate branch I'm preparing for ISTL will add support for multiple RHS vectors using vectorization.

The branch collects a set of helper classes which allow to add vectorization support to your code with moderate effort. Mainly this means that we have a couple of utility functions, which work for scalar data types, ranges and SIMD data types alike.

Added 7 commits:

• a6c74cf8 - [test] (re)enable the existing range checks in matrix tests
• 522bc0e2 - [test] don't check the matrix interface for std::vector or C arrays, we require a richer interface
• 2abb3bd4 - [densematrix] reenable and fix broken check, to avoid aliasing in mv and mtv
• d33190bc - [densematrix] use the correct field_type to reset the output vector during mv and mtv
• bdf74dca - [densematrix] use the correct scaling parameter for usmv and friends
• affef6f2 - [test] test fieldmatrix with mixed precision
• 1359dc38 - [cmake] add test to find the Vc vectrization library

Added 100 commits:

• 1359dc38...5438c22b - 86 commits from branch master
• cb543d57 - [cmake] add test to find the Vc vectrization library
• b29ff765 - [cmake] remove FindVc, as it is distributed with Vc
• a9b72a9a - [cmake] simplify Vc handling and add HAVE_VC to config.h
• 6cf3e5ec - [cmake] don't warn if FindVc was not found
• cb64e19d - [cmake] again refator the Vc detection and add again the add_dune_vc_flags command
• 0d9a417a - [typetraits] add a new trait to check for ranges
• 5b856431 - [add] helper classes for reduction-type operations on ranges
• 928feb94 - [add,simd] add specializiation of range utilities for VC simd vectors
• 063b7ecc - [simd] add cond operator
• 0d9865fa - [simd] retrieve the mask type from the vector type
• 26846c7a - [simd] make the default cond a bit more general
• b8480fb5 - [simd] fix scalar cond(...)
• 3ab2dde3 - [simd] move the cond function to a separate header
• 420ffea8 - [doc] add documentation for the rangeutilities

Title changed from [WIP] add support for vectorization library VC to add support for vectorization library VC

mentioned in merge request dune-istl!17 (merged)

I rebased the branch and added set of helper functions necessary to implement dune-istl!17 (merged)

Please comment.

I dislike the external dependency. VC seems to be a very tiny project, the name is ambiguous and I did not find a reference.

I fear this will become a feature only used by few, because it is to cumbersome to install the external dependency. We have / had similar situations with Grape, ARPPACK, NETLIB, psurface, AmiraMesh. I would prefer to put it into a dune-vc module. I don't know whether that's feasible.

The project lives at https://github.com/VcDevel/Vc with documentation at https://web-docs.gsi.de/~mkretz/Vc-master/ as far as I can see.

Yeah, right. Ambiguity myself! The references are not documented in the code or even better in the Doxygen + Sphinx documentation.

@gruenich I don't get your point. Why do you consider it a problem to an additional optional dependency. It is foundation stuff and thus I consider dune-common the right place for this. It is far too small for a separate module on it's own. It is actively developed, the maintainer is responsive and the concepts are actively discussed for a future C++ standard in concurrency section, see N4184 and N4185.

Regarding the link to the web-site you are right, I should add this, but you seem to be generally reserved regarding such an additional feature.

Up to now our policy was that we add features if they are not too invasive and people need them.

Status changed to merged

Great, we add optional dependencies to third party libraries without a proper discussion! My objections were not refuted. Nobody explicitly supported this merge request. Ok, Jö merged it and Markus commented on it at a different location. But no thumbs up or supportive comments.

I want to stress that I am not against this feature per se. But I am against adding personal balconies. These features are difficult to test for release managers.

Sorry, this was a PEBKAC. I did not intent to merge this. I'm gonna try and see if I can clean this up somehow.

Let's wait what the discussion will bring. If there is a majority for leaving it in, we let it be. Otherwise we still can revert the merge.

mentioned in issue #26 (closed)

mentioned in commit e4571c8d

mentioned in merge request !73 (closed)

mentioned in commit 474b5e9f

mentioned in merge request !74 (merged)

mentioned in merge request !75 (closed)

mentioned in merge request dune-geometry!13 (closed)

mentioned in commit 5afd88aa

The merge has been reverted. It is still not 100% clear whether this branch will be reverted, or whether there will be a new one.

Reassigned to @joe

Assignee removed

mentioned in merge request !81 (merged)

Since the merge-request can't be unmerged, even though I resurrected the branch feature/vc in an unmerged state, this merge request is no longer useful and discussion should continue in !81 (merged).

mentioned in commit c955776c

Mentioned in commit c955776c

Mentioned in commit 474b5e9f

Mentioned in commit 5afd88aa

mentioned in commit dune-istl@7843720d