The current implementation of the AMD HIP compiler adds default compiler
flags to attempt to inline everything possible. This is wrecking havoc
with the `Variant::CastAndCall` function, whose implementation has one
or more large switch statements with each case calling a different
potentially inline function. In some parts of the VTK-m code, this is
dragging the compilation on for days as it tries to resolve a
`Variant::CastAndCall` within a `Variant::CastAndCall`. This will
probably need to be addressed in the compiler, but meanwhile we will
force the inlining to be turned off for the function called by
`Variant::CastAndCall`. It is unclear if this will result in some extra
runtime overhead, but the change is worth it to get reasonable compile
times.
Thanks to Nick Curtis for tracking this down and providing the solution.
The previous implementation of `Variant`'s `CastAndCall` generated a
switch statement with 20 cases (plus a default) regardless of how many
types were handled by the `Variant` (with the excess doing nothing
useful). This reduced the amount of code, but caused the compiler to
have to build many more instructions (and optimize for them). This in
turn lead to large compile times and unnecessary large libraries/
executables.
This change makes a different function to use for `CastAndCall` so that
the number of cases in the switch matches exactly the number of types in
the `Variant`'s union.
Because the size of VariantImplDetail.h was getting large, I also
reduced the maximum expansions for the code. This does not seem to
negatively affect compile time, and I doubt it will have an noticible
difference in running time (when in release mode).
I also modified some other parts of this code to match the expansion
without making unnecessary defaults.
Recently, an instantiation method was added to the VTK-m configuration
files to set up a set of source files that compile instances of a template.
This allows the template instances to be compiled exactly once in separate
build files.
However, the implementation made the assumption that the instantiations
were happening for VTK-m filters. Now that the VTK-m filters are being
redesigned, this assumption is broken.
Thus, the instantiation code has been redesigned to be more general. It can
now be applied to code within the new filter structure. It can also be
applied anywhere else in the VTK-m source code.
In pretty much any practical circumstance, whenusing `ListAll` or
`ListAny`, you have a list of types on which you run some sort of
predicate on each item in the list to determine whether any or all of
the items match the predicate. To make this easier, add a second
argument to `ListAll` and `ListAny` to provide a predicate that will
automatically be added.
If no predicate is given, then the operation is run directly on the
list. This is implemented by just using an identity operation.
GCC 11 is having trouble compiling brigand.hpp at all, even before we
instantiate any templates. Since we no longer need it, let's get rid of
it. It was always placed in an internal namespace.
Add deprecation warnings to the code whenever someone uses brigand.hpp.
We are no longer supporting this header file, but we'll give code a
chance to transition off of it.
Also added some other deprecation warnings to other header files that
are themselves deprecated but only issued warnings if you used something
in it.
These new features to VTK-m lists allow you to compute a single value
from a list. `ListReduce` allows you to compute a value based on a
predicate. `ListAll` and `ListAny` use this feature to determine if all
or any of a list of `true_type` or `false_type` objects are true.
Previously, if you called `Get` on a `Variant` with a type that is not
in the list of types supported by the `Variant`, that would attempt to
look up the type at index `-1` and could spin the compiler into an
endless loop.
Instead, check for the case where you are attempting to get a type from
the `Variant` not listed in its templat arguments. In this case, instead
of producing a compiler error, produce a runtime error. Although this
increases the possibility that a bad compile path is being generated, it
simplifies creating templated code that produces cases we don't care
about.
Deprecate `VirtualObjectHandle` and all other classes that are used to
implement objects with virtual methods in the execution environment.
Additionally, the code is updated so that if the
`VTKm_NO_DEPRECATED_VIRTUAL` flag is set none of the code is compiled at
all. This opens us up to opportunities that do not work with virtual
methods such as backends that do not support virtual methods and dynamic
libraries for CUDA.
For some reason some versions of the CUDA compiler would return true for
`is_trivially_copyable` on a `VariantUnion` even when the types of the
union caused the copy constructor to get deleted.
Solve the problem by using `AllTriviallyCopyable` instead of directly
caling `is_trivially_copyable` on the union.
Nvcc was having troubles resolving the return type of the overloaded
function to get a value out of a `VariantUnion`. Replace the
implementation with a class with specializations. This is more verbose,
but easier on the compiler.
Create a `VaraintUnion` that is an actual C++ `union` to store the data
in a `Variant`.
You may be asking yourself, why not just use an `std::aligned_union`
rather than a real union type? That was our first implementation, but
the problem is that the `std::aligned_union` reference needs to be
recast to the actual type. Typically you would do that with
`reinterpret_cast`. However, doing that leads to undefined behavior. The
C++ compiler assumes that 2 pointers of different types point to
different memory (even if it is clear that they are set to the same
address). That means optimizers can remove code because it "knows" that
data in one type cannot affect data in another type. To safely change
the type of an `std::aligned_union`, you really have to do an
`std::memcpy`. This is problematic for types that cannot be trivially
copied. Another problem is that we found that device compilers do not
optimize the memcpy as well as most CPU compilers. Likely, memcpy is
used much less frequently on GPU devices.
I have run into strange problems with reference types sneaking into
templates. Reference types can cause weird errors when passing things
across hosts and devices, and it's best not to let them sneak into an
object like Varient where they become more difficult to check for.
There appears to be a bug in GCC where if you mixed C++ attributes like
`[[deprecated]]` with GNU attributes like `__attribute__(())`, you will
get a compile error. This can be a problem when using attributes to both
set the export (i.e. visibility) of an item and deprecating the same
item.
This problem has been encountered before. Commit
34b0bba84207a89e8fddfe62e7a1ff30b1b53a18 fixed the problem by using
`[[gnu::visibility()]]` instead of `__attribute__()` in the export
macros. This works fine for export macros defined by VTK-m headers such
as `VTKM_ALWAYS_EXPORT`. Unfortunately, we have little control over the
export macros that CMake automatically creates. Rather than rewrite the
CMake export code, we go the other way and use `__attribute__()` for all
exports _and_ the depreciated attribute.
7475c318b VTK-m now uses CMake's future HIP lang for Kokkos+HIP
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !2351
Many of the fancy `ArrayHandle`s are read-only and therefore connot
really create write portals. Likewise, many `ArrayHandle`s (both read-
only and read/write) have no way to resize themselves. In this case,
implementing the `CreateWritePortal` and `ResizeBuffers` methods in the
`Storage` class was troublesome. Mostly they just threw an exception,
but they also sometimes had to deal with cases where the behavior was
allowed.
To simplify code for developers, this introduces a pair of macros:
`VTKM_STORAGE_NO_RESIZE` and `VTKM_STORAGE_NO_WRITE_PORTAL`. These can
be declared in a `Storage` implementation when the storage has no viable
way to resize itself and create a write portal, respectively.
Having boilerplate code for these methods also helps work around
expected behavior for `ResizeBuffers`. `ResizeBuffers` should silently
work when resizing to the same size. Also `ResizeBuffers` should behave
well when resizing to 0 as that is what `ReleaseResources` does.
The `Variant` class has separate implementations for its move and copy
constructors/assignment operators depending on whether the classes it
holds can be trivially moved. If the objects are trivial, Variant is
trivial as well. However, in the case where the objects are not trivial,
special construction and copying needs to be done.
Previously, the non-trivial `Variant` defined a move constructor that
did a byte copy of the contained object and reset the right hand side
object so that it did not attempt to destroy the object. That usually
works because it guarantees that only one version of the `Variant` will
attempt to destroy the object and its resources should be cleaned up
correctly.
But C++ is a funny language that lets you do weird things. Turns out
there are cases where moving the location of memory for an object
without calling the proper copy method can invalidate the object. For
example, if the object holds a pointer to one of its own members, that
pointer will become invalid. Also, if it points to something that points
back, then the object will need to update those pointers when it is
moved. GCC's version of `std::string` seems to be a type like this.
Solve the problem by simply deleting the move constructors. The copy
constructors and destructor will be called instead to properly manage
the object. A test for these conditions is added to `UnitTestVariant`.
The `Variant` class is templated to hold objects of other types.
Depending on whether those objects of are meant to be used in the
control or execution side, the methods on `Variant` might need to be
declared with (or without) special modifiers. We can sometimes try to
compile the `Variant` methods for both host and device and ask the
device compiler to ignore incompatibilities, but that does not always
work.
To get around that, create two different implementations of `Variant`.
Their API and implementation is exactly the same except one declares its
methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
Although `vtkm::internal::Variant` respected the trivially copyable
attribute of the types it contains, it was never totally trivial (i.e.
`std::is_trivial<Variant<...>>` was never true). The reason was that
`Variant` was initializing its `Index` parameter to signify that it was
not initialized. However, the fact that `Index` was initialized meant
that it was not trivially constructed.
Now, `Variant` type checks its types to see if they are all trivially
constructible. If so, it makes itself trivially constructible.
This means that `Index` may or may not be valid if `Variant` is
constructed without an argument. This in turn means that the result of
`Variant::IsValid` becomes undefined. That should be OK in practice.
`Index` will "point" to an uninitialized object, but that object is
trivially constructed anyway. However, that could cause problems if
developers used `IsValid` to determine if something is selected.
As we remove more and more virtual methods from VTK-m, I expect several
users will be interested in completely removing them from the build for
several reasons.
1. They may be compiling for hardware that does not support virtual
methods.
2. They may need to compile for CUDA but need shared libraries.
3. It should go a bit faster.
To enable this, a CMake option named `VTKm_NO_DEPRECATED_VIRTUAL` is
added. It defaults to `OFF`. But when it is `ON`, none of the code that
both uses virtuals and is deprecated will be built.
Currently, only `ArrayHandleVirtual` is deprecated, so the rest of the
virtual classes will still be built. As we move forward, more will be
removed until all virtual method functionality is removed.
c689a68c5 Suppress bad deprecation warnings in MSVC
a3f23a03b Do not cast to ArrayHandleVirtual in VariantArrayHandle::CastAndCall
f6b13df51 Support coordinates of both float32 and float64
453e31404 Deprecate ArrayHandleVirtualCoordinates
be7f06bbe CoordinateSystem data is VariantArrayHandle
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2177
The Microsoft compiler has this annoying and stupid behavior where if
you have a generic templated method/function and that method is
instantiated with a deprecated class, then the compiler will issue a
C4996 warning even if the calling code is suppressing that warning
(because, for example, you are implementing other deprecated code and
the use is correct). There is no way around this other than suppressing
the warnings for all uses of the templated method.
A recent change to the continuous integration setup has caused
`UnitTestArrayPortalValueReference` to fail on one platform.
The problem was that the test was doing two unsafe things with the
right-shift assignment operator. The first unsafe thing was using itself
as the operand.
```cpp
ref >>= ref;
```
This causes clang to give a "self assign overload" warning. Using a
variable as its own operand for a compute assign operation isn't great
style, but for some operations it can cause weird errors. The reason for
the warning is that for a true integer shift operation, the compiler
will recognize that the result should be 0. So, when using this on base
integer types, you will get 0. But overloads can give you something
different, so that might lead to unexpected results. Because we _are_
using an overload (for the `ArrayPortalValueReference` class), the
compiler tells us we can get potentially unexpected results.
OK. That seems like something we can safely ignore (and were ignoring
for some time). After all, the whole point of the
`ArrayPortalValueReference` operators is to behave exactly the same as
the values they wrap. That brings us to the second unsafe thing the test
was doing: using an invalid value as the right hand operation. And this
is where things get weird.
The test was specifically failing when being run on `Int32`. It was
setting the underlying value for `ref` to be `1000` to start with. So
the expression `ref >>= ref` was trying to right shift `ref` by 1000
bits. Logically, this should of course give you 0. However, shifting a
number by more bits than exist causes undefined behavior (c.f.
https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand).
You might not get back the expected value, and this is exactly what was
happening.
What I think happened was that the compiler determined that any valid
shift would be contained in 5 bits, so it truncated the value (1000) to
the least signifcant 5 bits (which happens to be 8). It then shifted
1000 by 8 and got the value 3 instead of 0.
The fix picks an operand number that is sure to be valid.
`assert` is supported on recent CUDA cards, but compiling it appears to be
very slow. By default, the `VTKM_ASSERT` macro has been disabled whenever
compiling for a CUDA device (i.e. when `__CUDA_ARCH__` is defined).
Asserts for CUDA devices can be turned back on by turning the
`VTKm_NO_ASSERT_CUDA` CMake variable off. Turning this CMake variable off
will enable assertions in CUDA kernels unless there is another reason
turning off all asserts (such as a release build).
