Using GCC 9.2 the pre change vtkm::filter::Threshold would
take 31.84sec to compile and use 1.1GB of memory. After
these changes the filter takes 24.16sec to compile and
uses 885MB of memory.
CMake 3.16 includes support for unity builds which merge multiple
translation units together automatically for faster builds.
A couple of translation units in VTK-m already require lots of
system memory, and merging them actually decreases compile performance
There is some behavior of GCC compilers before GCC 9.0 that is
incompatible with the specification of OpenMP 4.0. The workaround was
using the workaround any time a GCC compiler >= 9.0 was used. The proper
behavior is to only use the workaround when the GCC compiler is being
used and the version of the compiler is less than 9.0.
Also, switch to using VTKM_GCC to check for the GCC compiler instead of
__GNUC__. The problem with using __GNUC__ is that many other compilers
pretend to be GCC by defining this macro, but in cases like compiler
workarounds it is not accurate.
Older GCC compilers were giving warnings in the operator of the
GeneratePoints worklets for tubes because they could not completely
determine that variables were being properly initialized in the first
loop iteration (and therefore initialized for every subsequent
iteration). Fixed that by moving the initialization for the first
iteration outside of the loop.
Although GCC 4.8 and 4.9 claim to be C++11 compliant, there are a few
C++11 features they do not support. One of these features is
std::is_trivially_copyable. So on these platforms, do not attempt to use
it. Instead, treat nothing as trivially copyable.
The code from the previous commit was causing one of the dashboards,
which is using gcc-7, to produce the following warning:
In file included from ../testing/UnitTestVariant.cxx:11:0:
../Variant.h: In function 'void {anonymous}::TestCopyDestroy()':
../Variant.h:269:5: warning: '<anonymous>' may be used uninitialized in this function [-Wmaybe-uninitialized]
this->Storage = std::move(rhs.Storage);
^~~~
At best, this warning is not helpful as it does not seem to point to
anything that could be used uninitialized. At worst, it might be a
compiler bug. A Google search finds a few similar bugs although none I
can assert with any confidence of this issue. However, many reported
bugs and issues point to the use of anonymous namespaces. So, I'm going
to attempt to fix the problem by removing anonymous namespaces.
Hopefully it will fix the warning or at least point me to something
concrete that I can fix.
The Variant template can hold any type. If it is holding a type that is
non-copyable, then it has to make sure that appropriate constructors,
copiers, movers, and destructors are called.
Previously, these were called even the Variant was holding a trivially
copyable class because no harm no foul. If you were holding a trivially
copyable class and did a memcpy, that work work, which should make it
possible to copy between host and device, right?
In theory yes, but in practice no. The problem is that Cuda is
outsmarting the code. It is checking that Variant is not trivially-
copyable by C++ semantics and refusing to push it.
So, change Variant to check to see if all its supported classes are
trivially copyable. If they are, then it use the default constructors,
destructors, movers, and copiers so that C++ recognizes it as trivially
copyable.
79f7f8275 Fix UnitTestError failure
901711bff Fix test failure due to floating point issues
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1896
This file was using the Matrix class but not including Matrix.h. When I
tried to use the MeshQuality filter in an example that did not include
Matrix.h on its own, I got a compile error.
If a worklet doesn't explicitly state an ExecutionSignature, VTK-m
assumes the worklet has no return value, and each ControlSignature
argument is passed to the worklet in the same order.
For example if we had this worklet:
```cxx
struct DotProduct : public vtkm::worklet::WorkletMapField
{
using ControlSignature = void(FieldIn, FieldIn, FieldOut);
using ExecutionSignature = void(_1, _2, _3);
template <typename T, vtkm::IdComponent Size>
VTKM_EXEC void operator()(const vtkm::Vec<T, Size>& v1,
const vtkm::Vec<T, Size>& v2,
T& outValue) const
{
outValue = vtkm::Dot(v1, v2);
}
};
```
It can be simplified to be:
```cxx
struct DotProduct : public vtkm::worklet::WorkletMapField
{
using ControlSignature = void(FieldIn, FieldIn, FieldOut);
template <typename T, vtkm::IdComponent Size>
VTKM_EXEC void operator()(const vtkm::Vec<T, Size>& v1,
const vtkm::Vec<T, Size>& v2,
T& outValue) const
{
outValue = vtkm::Dot(v1, v2);
}
};
The older Xcode 9 compiler has troubles with ArrayHandleDecorator that
are similar to those of earlier Microsoft and Cuda compilers.
Note that the logic behind the changed compiler check has a lot of
guesswork involved. I noticed this problem on a laptop with Xcode 9
installed. However, even though Xcode uses the clang compiler, it
notoriously does not return the actual clang version. Instead, it
returns some toolchain version that has nothing to do with it. I'm
pretty sure Xcode 9 is using clang version 4 under the covers, but
__clang_major__ reports 9. Oddly, Xcode 10 reports __clang_major__ as 8,
so that's not too much help. So instead, we check for
__apple_build_version__, which returns the Xcode version (sort of) and
that seems a reasonable comparison.
Although I have not tried it, I'm willing to bet that the older clang
outside of Xcode will also have issues. Here is where the real guesswork
takes place since I don't have handy compilers to try. Like I said, I
think the internet claims that Xcode 9 is using clang 4, so also add to
the check any compiler that reports itself clang 4 or below.