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.

See also: !16 (merged), dune-istl!17 (merged), dune-geometry!13 (closed).

Note: This is the followup merge request to !16 (merged). The original was merged accidentially and had to be reverted, see #26 (closed). The branch had to be rebased; if you had checked out an earlier version of feature/vc you may need to take special action to rebase onto the new branch.#

mentioned in issue #26 (closed)

mentioned in merge request !16 (merged)

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

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

mentioned in merge request !75 (closed)

What's the status, here? Is there anything left to be done or can we merge this?

Well, no, there are still open questions.

• I once asked who would be in favor of getting this feature, and I got the impression only Christian, Jö and Markus would be interested, at least they took part in the discussion.
• It remained an open question whether the current implementation is too Vc-devel specific. I did not hear an answer regarding this concern.

Have a look at !16 (merged) and some more places.

@gruenich: Basically you want the big solution (and I guess everybody would agree to that). This merge request is just about adding a configure test for Vc and adding a small layer of compatibility functions, so that Vc stuff can be used in a non-intrusive way.

I think we should discuss the big solution (i.e., a compatibility layer) in a separate issue.

PS: I want this, too. So count me in.

I expressed my concerns that Vc would be a pet project of Christian. It turned out that you are interested, too. In the mean time I learned that Krita (KDE graphics software) uses Vc, too. The support for the third-party project and within the Dune developer crowd seems ok.

My sole request is to change the name from Vc, which is hardly google-able, to either VcDevel or Vc-devel. At least the packages for openSuse have the devel in the name, so do other references to this project.

Unmarked this merge request as a Work In Progress

I don't get, how you want the name to be changed? We only reference the name in the test, which nothing we can change, as we rely on the upstream test.

Maybe we can reference the web address of vc in the documentation?

Apart from that, Vc is easily found on google: 'vc vectorization'

HAVE_VCDEVEL, VcDevel_FOUND, AddVcDevelFlags.cmake and so on.

Martin, that's my point, googling Vc leads to nowhere; except for Venture capital and some Stuttgart Volleyball club, ymmv. If you have no idea what vc is related to, it's difficult to find out more about it. Having the URL in the documenation is mandatroy.

regarding the name... as I said I do not intend to modify the upstream cmake files. Thus the name is set in stone. I agree with Martin, that we can and should add the link. Furthermore I don't consider VcDevel a particularly good name. "devel " or "dev" usually indicates that we are refering to the development package instead of the binary package. Shall we now also search for MPIDevel and GMPDevel? While the name of the project was not particularly well chose it is nothing we can change.

Other refer to Vc by Vc-devel, too. But ok, then let's live with a bad name. I will no longer stand in your way introducing vc.

! + the user should never be bothered with this. He shall use the simd abstractions, but never use HAVE_VC or similar.

Every configure run will present that Vc is (not) found. Without any further information.

But this is something we can not change unless we copy the FindVc.cmake and modify it. It was you who pointed out, that one should not copy Find*cmake files to the project, but just rely on cmake detecting them.