Arithmetic types for alignment debugging

This class wraps fundamental arithmetic types and makes them overaligned. Actual alignment is checked at runtime in the constructor/destructor.

AVX SIMD types are overaligned, that is, some hardware instructions require them to be aligned to 32 bytes (or greater), while GCC only guarantees 16 bytes alignment. When allocated on the stack, the compiler still honours the overalignment, but typically not when allocated dynamically. This means that containers, that should support overaligned types, must use a special allocator to allocate internal memory that is supposed to hold objects of such types. This is however not always implemented correctly.

Debugging and unit testing with AVX SIMD types is not always possible, for instance because the required hardware or required libraries are not readily available. This makes is difficult to find incorrect use of allocators in containers.

This is where these overaligned wrapper types come in. They can be used for debugging and unit testing instead of SIMD types, and will work without particular hardware or libraries.

Depends: !225 (merged)

Due for merge: 2017-05-02

[WIP] Needs support for <cmath> functions.
Missing:

• Support for <cmath> functions with more than one argument (can be added at a later time when someone needs them).

marked as a Work In Progress

Turns out that to debug dune/istl/test/multirhstest with this type we need support for sqrt() and the other functions from <cmath>. Turns out that when you add a Dune::sqrt() overload for the alignment debugging type, the world collapses, because there are places in dune where people forgot the using std::sqrt; before calling sqrt() on e.g. a double value.

Without Dune::sqrt(), a sqrt(1.0) in the Dune namespace will find the ::sqrt() candidates from <math.h> via unqualified lookup, and will find nothing via ADL. It will then select the ::sqrt(double) overload.

With Dune::sqrt(), a sqrt(1.0) in the Dune namespace will find ::Dune::sqrt() candidates via unqualified lookup. It will again find nothing via ADL, since double has no associated namespaces. No overload of ::Dune::sqrt() matches the double argument, so the lookup fails.

Possible resolutions:

1. Put sqrt(AlignedNumber<...>) and friends into namespace Dune anyway, and fix all the bugs. Drawback: I can only fix the bugs that are in the core modules, and that are found by unit tests
2. Define sqrt(AlignedNumber<...>) and friends as friend functions inside AlignedNumber, and do not declare them outside. This means that those functions will not be found by unqualified lookup, only by ADL. May not be possible to do right for functions with multiple argument (e.g. pow()): where do you put the overload for pow(AlignedNumber<double, ...>, AlignedNumber<int, ...>)?
3. Move AlignedNumber into a sub-namespace of Dune, define the overloads there, and then do using SubNamespace::AlignedNumber inside Dune. A bit ugly, but should work.

added 4 commits

• cf4e08eb - [AlignedNumber] Add simd-like free functions.
• b43a3f51 - [AlignedNumber] Add inserters and extractors.
• 02292738 - [AlignedNumber] Provide <cmath> functions.
• 9eeedc2a - [debugalign] Mention how to do alignment right, once we have library support.

Compare with previous version

added 2 commits

• f5cbc684 - [debugalign] Implement AlignedNumber in a sub-namespace of Dune.
• 18837382 - [debugalign] Clarify error message: alignment is given in hex.

Compare with previous version

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

@joe did I miss something or does the type actually not specify the required alignement using alignas. This will lead to false positives for stack allocated objects.

sorry for the noise, it is there.

But I found something else, we need an aligned allocator. I have implemented a simple one based on the MallocAllocator. I'll clean this up and push the changes.

added 1 commit

• 2323db7e - implement AlignedAllocator

Compare with previous version

added 2 commits

• a45f03fa - [AlignedNumber] Fix default template arguments for clang.
• 94cbe250 - Merge remote-tracking branch 'origin/feature/debugalign' into feature/debugalign

Compare with previous version

In order to fix ISTL, I suggest to merge this MR and create a second one for the additional operations, together with the appropriate test.

added 23 commits

• 94cbe250...3fcb1cf2 - 20 commits from branch master
• 46cb6931 - [AlignedNumber] add unary function real
• d6a6abb7 - [AlignedNumber] add specialization of SimdScalarTypeTraits
• 7e4b9296 - Merge remote-tracking branch 'origin/master' into feature/debugalign

Compare with previous version

@joe, is there a reason not to merge yet?

I guess we can defer the multi-argument <cmath> functions to a later time, when they are actually needed. I'm going to try to resolve the merge conflict, then the only thing missing is the two-week mandatory simmering for new features.

added 35 commits

• 7e4b9296...c4d02b07 - 33 commits from branch master
• bfac60ee - [AlignedNumber] Cleanup.
• ed778908 - Merge remote-tracking branch 'origin/master' into feature/debugalign

Compare with previous version

unmarked as a Work In Progress

I fixed the merge conflict, removed the [WIP] and set the due date in two weeks.

merged

mentioned in commit 1d2a46ac