Shuenhoy/vtk-m
1
0
Fork 0
mirror of https://gitlab.kitware.com/vtk/vtk-m synced 2024-10-05 01:49:02 +00:00
Code Issues 2 Actions Packages Projects Releases Wiki Activity
master
vtk-m/vtkm/internal/VariantImplDetail.h.in

483 lines
16 KiB
C
Raw Permalink Normal View History

Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
//============================================================================
// Copyright (c) Kitware, Inc.
// All rights reserved.
// See LICENSE.txt for details.
//
// This software is distributed WITHOUT ANY WARRANTY; without even
// the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
// PURPOSE. See the above copyright notice for more information.
//============================================================================
$# This file uses the pyexpander macro processing utility to build the
$# FunctionInterface facilities that use a variable number of arguments.
$# Information, documentation, and downloads for pyexpander can be found at:
$#
$# http://pyexpander.sourceforge.net/
$#
$# To build the source code, execute the following (after installing
$# pyexpander, of course):
$#
$# expander.py VariantDetail.h.in > VariantDetail.h
$#
$# Ignore the following comment. It is meant for the generated file.
// **** DO NOT EDIT THIS FILE!!! ****
// This file is automatically generated by VariantDetail.h.in
Make separate exec and cont versions of Variant 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`.
2020-10-06 21:57:04 +00:00
#if !defined(VTK_M_DEVICE) || !defined(VTK_M_NAMESPACE)
#error VarianImplDetail.h must be included from VariantImpl.h
Do not attempt to move non-trivial objects in Variant 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`.
2020-10-08 18:02:27 +00:00
// Some defines to make my IDE happy.
#define VTK_M_DEVICE
#define VTK_M_NAMESPACE tmp
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
#endif
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
#include <vtkm/List.h>
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
#include <vtkm/Types.h>
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
#include <vtkm/internal/Assume.h>
#include <vtkmstd/is_trivial.h>
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
Add an entry to VariantUnion to help compiler copy structs I've been seeing errors in a nightly build that compiles for CUDA Pascal using GCC5. The issue is that one of the `ArrayHandleMultiplexer` tests is failing to copy an implicit array correctly. I think the problem is that in this test the first and second type of the `Variant` are the same size, but the first type has some padding in the middle whereas the second type does not. When using this second type, the values in the same position of the padding of the first type don't seem to be initialized properly in the kernel invocation. My nonexhaustive experiment shows that things work OK as long as the first type is large enough and has no fillers. Enforce this by adding an internal entry to the union that is completely full.
2023-03-28 20:32:25 +00:00
#include <algorithm>
Fix issue with union placeholder on Intel compiler We have run into an issue with some Intel compilers where if a `union` contains a `struct` that has some padding for byte alignment, the value copy might skip over that padding even when the `union` contains a different type where those bytes are valid. This breaks the value copy of our `Variant` class. This is not a unique problem. We have seen the same thing in other compilers and already have a workaround for when this happens. The workaround creates a special struct that has no padding placed at the front of the `union`. The Intel compiler adds a fun twist in that this placeholder structure only works if the alignment is at least as high as the struct that follows it. To get around this problem, make the alignment of the placeholder `struct` at large as possible for the size of the `union`. It was taking too long to compile with a device. Redesign the placeholder to be simpler and compile faster.
2023-08-31 18:36:48 +00:00
#include <cstddef>
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
#include <type_traits>
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
$py(max_expanded=8)\
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
$# Python commands used in template expansion.
$py(
def type_list(num_params):
if num_params < 0:
return ''
result = 'T0'
for param in range(1, num_params + 1):
result += ', T%d' % param
return result
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
def typename_list(num_params):
if num_params < 0:
return ''
result = 'typename T0'
for param in range(1, num_params + 1):
result += ', typename T%d' % param
return result
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
)\
$#
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
$extend(type_list, typename_list)\
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
namespace vtkm
{
Make separate exec and cont versions of Variant 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`.
2020-10-06 21:57:04 +00:00
namespace VTK_M_NAMESPACE
{
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
namespace detail
{
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
// --------------------------------------------------------------------------------
// Helper classes to determine if all Variant types are trivial.
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
template <typename... Ts>
using AllTriviallyCopyable = vtkm::ListAll<vtkm::List<Ts...>, vtkmstd::is_trivially_copyable>;
Reduce the number of lines required to implement AllTrivially*
2021-03-30 20:05:53 +00:00
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
// Single argument version of is_trivially_constructible
template <typename T>
using Constructible = vtkmstd::is_trivially_constructible<T>;
Reduce the number of lines required to implement AllTrivially*
2021-03-30 20:05:53 +00:00
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
template <typename... Ts>
using AllTriviallyConstructible = vtkm::ListAll<vtkm::List<Ts...>, Constructible>;
Reduce the number of lines required to implement AllTrivially*
2021-03-30 20:05:53 +00:00
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
template <typename... Ts>
using AllTriviallyDestructible =
vtkm::ListAll<vtkm::List<Ts...>, vtkmstd::is_trivially_destructible>;
Add an entry to VariantUnion to help compiler copy structs I've been seeing errors in a nightly build that compiles for CUDA Pascal using GCC5. The issue is that one of the `ArrayHandleMultiplexer` tests is failing to copy an implicit array correctly. I think the problem is that in this test the first and second type of the `Variant` are the same size, but the first type has some padding in the middle whereas the second type does not. When using this second type, the values in the same position of the padding of the first type don't seem to be initialized properly in the kernel invocation. My nonexhaustive experiment shows that things work OK as long as the first type is large enough and has no fillers. Enforce this by adding an internal entry to the union that is completely full.
2023-03-28 20:32:25 +00:00
// --------------------------------------------------------------------------------
// Helper functions to determine the maximum type size.
#if defined(VTKM_GCC) && (__GNUC__ == 5)
// GCC5 gives an error with `sizeof(Ts)...` for an unexpanded parameter pack.
template <typename T0>
constexpr std::size_t MaxSizeOf()
{
return sizeof(T0);
}
template <typename T0, typename T1, typename... Ts>
constexpr std::size_t MaxSizeOf()
{
return std::max(sizeof(T0), MaxSizeOf<T1, Ts...>());
}
#else
template <typename... Ts>
constexpr std::size_t MaxSizeOf()
{
return std::max({ sizeof(Ts)... });
}
#endif
Fix issue with union placeholder on Intel compiler We have run into an issue with some Intel compilers where if a `union` contains a `struct` that has some padding for byte alignment, the value copy might skip over that padding even when the `union` contains a different type where those bytes are valid. This breaks the value copy of our `Variant` class. This is not a unique problem. We have seen the same thing in other compilers and already have a workaround for when this happens. The workaround creates a special struct that has no padding placed at the front of the `union`. The Intel compiler adds a fun twist in that this placeholder structure only works if the alignment is at least as high as the struct that follows it. To get around this problem, make the alignment of the placeholder `struct` at large as possible for the size of the `union`. It was taking too long to compile with a device. Redesign the placeholder to be simpler and compile faster.
2023-08-31 18:36:48 +00:00
// --------------------------------------------------------------------------------
// Helper functions to determine the maximum alignment size.
template <typename... Ts>
constexpr std::size_t MaxAlignmentOf()
{
return std::max({ std::alignment_of<Ts>::value... });
}
Add an entry to VariantUnion to help compiler copy structs I've been seeing errors in a nightly build that compiles for CUDA Pascal using GCC5. The issue is that one of the `ArrayHandleMultiplexer` tests is failing to copy an implicit array correctly. I think the problem is that in this test the first and second type of the `Variant` are the same size, but the first type has some padding in the middle whereas the second type does not. When using this second type, the values in the same position of the padding of the first type don't seem to be initialized properly in the kernel invocation. My nonexhaustive experiment shows that things work OK as long as the first type is large enough and has no fillers. Enforce this by adding an internal entry to the union that is completely full.
2023-03-28 20:32:25 +00:00
// --------------------------------------------------------------------------------
Test variant arguments to worklets Add a regression test for passing a variant as an argument to a worklet. Variants are tricky objects, and the compiler might make some strange assumptions during optimization. One case that popped up in particular was when a variant contained two objects with the same `sizeof` but the first object had padding. When the variant contained the second object, the value under the padded part of the first object was not set.
2023-04-04 23:14:38 +00:00
// Placeholder for a fully used structure of the given type.
Fix issue with union placeholder on Intel compiler We have run into an issue with some Intel compilers where if a `union` contains a `struct` that has some padding for byte alignment, the value copy might skip over that padding even when the `union` contains a different type where those bytes are valid. This breaks the value copy of our `Variant` class. This is not a unique problem. We have seen the same thing in other compilers and already have a workaround for when this happens. The workaround creates a special struct that has no padding placed at the front of the `union`. The Intel compiler adds a fun twist in that this placeholder structure only works if the alignment is at least as high as the struct that follows it. To get around this problem, make the alignment of the placeholder `struct` at large as possible for the size of the `union`. It was taking too long to compile with a device. Redesign the placeholder to be simpler and compile faster.
2023-08-31 18:36:48 +00:00
// This placeholder is used for compilers that do not correctly copy `struct`s
// in `union`s where some of the `struct`s have padding. This is added to the
// front of the `union` for the compiler to pick up and use.
//
// It is normally sufficient to have a full `struct`, but we have also encountered
// compilers that only use it if the alignment is at least as large. But we
// don't want the alignment too large because it can add unwanted padding
// elsewhere. Also, adding `alignas` did not work to resolve this problem for
// the compiler.
template <std::size_t Alignment>
struct TypeForAlignmentImpl;
template <>
struct TypeForAlignmentImpl<8>
Add an entry to VariantUnion to help compiler copy structs I've been seeing errors in a nightly build that compiles for CUDA Pascal using GCC5. The issue is that one of the `ArrayHandleMultiplexer` tests is failing to copy an implicit array correctly. I think the problem is that in this test the first and second type of the `Variant` are the same size, but the first type has some padding in the middle whereas the second type does not. When using this second type, the values in the same position of the padding of the first type don't seem to be initialized properly in the kernel invocation. My nonexhaustive experiment shows that things work OK as long as the first type is large enough and has no fillers. Enforce this by adding an internal entry to the union that is completely full.
2023-03-28 20:32:25 +00:00
{
Fix issue with union placeholder on Intel compiler We have run into an issue with some Intel compilers where if a `union` contains a `struct` that has some padding for byte alignment, the value copy might skip over that padding even when the `union` contains a different type where those bytes are valid. This breaks the value copy of our `Variant` class. This is not a unique problem. We have seen the same thing in other compilers and already have a workaround for when this happens. The workaround creates a special struct that has no padding placed at the front of the `union`. The Intel compiler adds a fun twist in that this placeholder structure only works if the alignment is at least as high as the struct that follows it. To get around this problem, make the alignment of the placeholder `struct` at large as possible for the size of the `union`. It was taking too long to compile with a device. Redesign the placeholder to be simpler and compile faster.
2023-08-31 18:36:48 +00:00
using type = vtkm::Int64;
Add an entry to VariantUnion to help compiler copy structs I've been seeing errors in a nightly build that compiles for CUDA Pascal using GCC5. The issue is that one of the `ArrayHandleMultiplexer` tests is failing to copy an implicit array correctly. I think the problem is that in this test the first and second type of the `Variant` are the same size, but the first type has some padding in the middle whereas the second type does not. When using this second type, the values in the same position of the padding of the first type don't seem to be initialized properly in the kernel invocation. My nonexhaustive experiment shows that things work OK as long as the first type is large enough and has no fillers. Enforce this by adding an internal entry to the union that is completely full.
2023-03-28 20:32:25 +00:00
};
template <>
Fix issue with union placeholder on Intel compiler We have run into an issue with some Intel compilers where if a `union` contains a `struct` that has some padding for byte alignment, the value copy might skip over that padding even when the `union` contains a different type where those bytes are valid. This breaks the value copy of our `Variant` class. This is not a unique problem. We have seen the same thing in other compilers and already have a workaround for when this happens. The workaround creates a special struct that has no padding placed at the front of the `union`. The Intel compiler adds a fun twist in that this placeholder structure only works if the alignment is at least as high as the struct that follows it. To get around this problem, make the alignment of the placeholder `struct` at large as possible for the size of the `union`. It was taking too long to compile with a device. Redesign the placeholder to be simpler and compile faster.
2023-08-31 18:36:48 +00:00
struct TypeForAlignmentImpl<4>
{
using type = vtkm::Int32;
};
template <>
struct TypeForAlignmentImpl<2>
{
using type = vtkm::Int16;
};
template <>
struct TypeForAlignmentImpl<1>
{
using type = vtkm::Int8;
};
template <std::size_t Alignment>
using TypeForAlignment = typename TypeForAlignmentImpl<Alignment>::type;
template <std::size_t Size, typename Word, bool = (Size >= 4)>
struct SizedPlaceholderImpl;
template <std::size_t Size, typename Word>
struct SizedPlaceholderImpl<Size, Word, true>
{
Word A;
Word B;
Word C;
Word D;
SizedPlaceholderImpl<Size - 4, Word> E;
};
template <typename Word>
struct SizedPlaceholderImpl<4, Word, true>
{
Word A;
Word B;
Word C;
Word D;
};
template <std::size_t Size, typename Word>
struct SizedPlaceholderImpl<Size, Word, false>
{
Word A;
SizedPlaceholderImpl<Size - 1, Word> B;
};
template <typename Word>
struct SizedPlaceholderImpl<1, Word, false>
Add an entry to VariantUnion to help compiler copy structs I've been seeing errors in a nightly build that compiles for CUDA Pascal using GCC5. The issue is that one of the `ArrayHandleMultiplexer` tests is failing to copy an implicit array correctly. I think the problem is that in this test the first and second type of the `Variant` are the same size, but the first type has some padding in the middle whereas the second type does not. When using this second type, the values in the same position of the padding of the first type don't seem to be initialized properly in the kernel invocation. My nonexhaustive experiment shows that things work OK as long as the first type is large enough and has no fillers. Enforce this by adding an internal entry to the union that is completely full.
2023-03-28 20:32:25 +00:00
{
Fix issue with union placeholder on Intel compiler We have run into an issue with some Intel compilers where if a `union` contains a `struct` that has some padding for byte alignment, the value copy might skip over that padding even when the `union` contains a different type where those bytes are valid. This breaks the value copy of our `Variant` class. This is not a unique problem. We have seen the same thing in other compilers and already have a workaround for when this happens. The workaround creates a special struct that has no padding placed at the front of the `union`. The Intel compiler adds a fun twist in that this placeholder structure only works if the alignment is at least as high as the struct that follows it. To get around this problem, make the alignment of the placeholder `struct` at large as possible for the size of the `union`. It was taking too long to compile with a device. Redesign the placeholder to be simpler and compile faster.
2023-08-31 18:36:48 +00:00
Word A;
Add an entry to VariantUnion to help compiler copy structs I've been seeing errors in a nightly build that compiles for CUDA Pascal using GCC5. The issue is that one of the `ArrayHandleMultiplexer` tests is failing to copy an implicit array correctly. I think the problem is that in this test the first and second type of the `Variant` are the same size, but the first type has some padding in the middle whereas the second type does not. When using this second type, the values in the same position of the padding of the first type don't seem to be initialized properly in the kernel invocation. My nonexhaustive experiment shows that things work OK as long as the first type is large enough and has no fillers. Enforce this by adding an internal entry to the union that is completely full.
2023-03-28 20:32:25 +00:00
};
Fix issue with union placeholder on Intel compiler We have run into an issue with some Intel compilers where if a `union` contains a `struct` that has some padding for byte alignment, the value copy might skip over that padding even when the `union` contains a different type where those bytes are valid. This breaks the value copy of our `Variant` class. This is not a unique problem. We have seen the same thing in other compilers and already have a workaround for when this happens. The workaround creates a special struct that has no padding placed at the front of the `union`. The Intel compiler adds a fun twist in that this placeholder structure only works if the alignment is at least as high as the struct that follows it. To get around this problem, make the alignment of the placeholder `struct` at large as possible for the size of the `union`. It was taking too long to compile with a device. Redesign the placeholder to be simpler and compile faster.
2023-08-31 18:36:48 +00:00
template <typename... Ts>
struct SizedPlaceholder
: SizedPlaceholderImpl<(MaxSizeOf<Ts...>() / MaxAlignmentOf<Ts...>()),
TypeForAlignment<MaxAlignmentOf<Ts...>()>>
{
Add an entry to VariantUnion to help compiler copy structs I've been seeing errors in a nightly build that compiles for CUDA Pascal using GCC5. The issue is that one of the `ArrayHandleMultiplexer` tests is failing to copy an implicit array correctly. I think the problem is that in this test the first and second type of the `Variant` are the same size, but the first type has some padding in the middle whereas the second type does not. When using this second type, the values in the same position of the padding of the first type don't seem to be initialized properly in the kernel invocation. My nonexhaustive experiment shows that things work OK as long as the first type is large enough and has no fillers. Enforce this by adding an internal entry to the union that is completely full.
2023-03-28 20:32:25 +00:00
};
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
// clang-format off
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
// --------------------------------------------------------------------------------
// Union type used inside of 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
Slight comment changes
2021-03-31 20:35:06 +00:00
// type cannot affect data in another type. (See Shafik Yaghmour's excellent writeup at
// https://gist.github.com/shafik/848ae25ee209f698763cffee272a58f8 for more details.) 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.
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
//
// Part of the trickiness of the union implementation is trying to preserve when the type is
// trivially constructible and copyable. The trick is that if members of the union are not trivial,
// then the default constructors are deleted. To get around that, a non-default constructor is
// added, which we can use to construct the union for non-trivial types. Working with types with
Slight comment changes
2021-03-31 20:35:06 +00:00
// non-trivial destructors are particularly tricky. Again, if any member of the union has a
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
// non-trivial destructor, the destructor is deleted. Unlike a constructor, you cannot just say to
// use a different destructor. Thus, we have to define our own destructor for the union.
// Technically, the destructor here does not do anything, but the actual destruction should be
// handled by the Variant class that contains this VariantUnion. We actually need two separate
// implementations of our union, one that defines a destructor and one that use the default
// destructor. If you define your own destructor, you can lose the trivial constructor and trivial
// copy properties.
//
// TD = trivially deconstructible
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
template <typename T0, typename... Ts>
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
union VariantUnionTD;
// NTD = non-trivially deconstructible
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
template <typename T0, typename... Ts>
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
union VariantUnionNTD;
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
$for(param_length in range(max_expanded))\
template <$typename_list(param_length)>
union VariantUnionTD<$type_list(param_length)>
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
{
Fix issue with union placeholder on Intel compiler We have run into an issue with some Intel compilers where if a `union` contains a `struct` that has some padding for byte alignment, the value copy might skip over that padding even when the `union` contains a different type where those bytes are valid. This breaks the value copy of our `Variant` class. This is not a unique problem. We have seen the same thing in other compilers and already have a workaround for when this happens. The workaround creates a special struct that has no padding placed at the front of the `union`. The Intel compiler adds a fun twist in that this placeholder structure only works if the alignment is at least as high as the struct that follows it. To get around this problem, make the alignment of the placeholder `struct` at large as possible for the size of the `union`. It was taking too long to compile with a device. Redesign the placeholder to be simpler and compile faster.
2023-08-31 18:36:48 +00:00
// Work around issue where some compilers miss initializing some struct members if another entry
// in the varient has a struct with padding. Place an item that requires everthing to be copied.
SizedPlaceholder<$type_list(param_length)> Placeholder;
Add an entry to VariantUnion to help compiler copy structs I've been seeing errors in a nightly build that compiles for CUDA Pascal using GCC5. The issue is that one of the `ArrayHandleMultiplexer` tests is failing to copy an implicit array correctly. I think the problem is that in this test the first and second type of the `Variant` are the same size, but the first type has some padding in the middle whereas the second type does not. When using this second type, the values in the same position of the padding of the first type don't seem to be initialized properly in the kernel invocation. My nonexhaustive experiment shows that things work OK as long as the first type is large enough and has no fillers. Enforce this by adding an internal entry to the union that is completely full.
2023-03-28 20:32:25 +00:00
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
$for(param_index in range(param_length + 1))\
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
T$(param_index) V$(param_index);
$endfor\
VTK_M_DEVICE VariantUnionTD(vtkm::internal::NullType) { }
VariantUnionTD() = default;
};
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
template <$typename_list(param_length)>
union VariantUnionNTD<$type_list(param_length)>
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
{
Fix issue with union placeholder on Intel compiler We have run into an issue with some Intel compilers where if a `union` contains a `struct` that has some padding for byte alignment, the value copy might skip over that padding even when the `union` contains a different type where those bytes are valid. This breaks the value copy of our `Variant` class. This is not a unique problem. We have seen the same thing in other compilers and already have a workaround for when this happens. The workaround creates a special struct that has no padding placed at the front of the `union`. The Intel compiler adds a fun twist in that this placeholder structure only works if the alignment is at least as high as the struct that follows it. To get around this problem, make the alignment of the placeholder `struct` at large as possible for the size of the `union`. It was taking too long to compile with a device. Redesign the placeholder to be simpler and compile faster.
2023-08-31 18:36:48 +00:00
// Work around issue where some compilers miss initializing some struct members if another entry
// in the varient has a struct with padding. Place an item that requires everthing to be copied.
SizedPlaceholder<$type_list(param_length)> Placeholder;
Add an entry to VariantUnion to help compiler copy structs I've been seeing errors in a nightly build that compiles for CUDA Pascal using GCC5. The issue is that one of the `ArrayHandleMultiplexer` tests is failing to copy an implicit array correctly. I think the problem is that in this test the first and second type of the `Variant` are the same size, but the first type has some padding in the middle whereas the second type does not. When using this second type, the values in the same position of the padding of the first type don't seem to be initialized properly in the kernel invocation. My nonexhaustive experiment shows that things work OK as long as the first type is large enough and has no fillers. Enforce this by adding an internal entry to the union that is completely full.
2023-03-28 20:32:25 +00:00
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
$for(param_index in range(param_length + 1))\
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
T$(param_index) V$(param_index);
$endfor\
VTK_M_DEVICE VariantUnionNTD(vtkm::internal::NullType) { }
VariantUnionNTD() = default;
VTK_M_DEVICE ~VariantUnionNTD() { }
};
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
$endfor\
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
template <$typename_list(max_expanded), typename... Ts>
union VariantUnionTD<$type_list(max_expanded), Ts...>
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
{
Add an entry to VariantUnion to help compiler copy structs I've been seeing errors in a nightly build that compiles for CUDA Pascal using GCC5. The issue is that one of the `ArrayHandleMultiplexer` tests is failing to copy an implicit array correctly. I think the problem is that in this test the first and second type of the `Variant` are the same size, but the first type has some padding in the middle whereas the second type does not. When using this second type, the values in the same position of the padding of the first type don't seem to be initialized properly in the kernel invocation. My nonexhaustive experiment shows that things work OK as long as the first type is large enough and has no fillers. Enforce this by adding an internal entry to the union that is completely full.
2023-03-28 20:32:25 +00:00
// Work around issue where CUDA sometimes seems to miss initializing some struct members
// if another entry in the varient has a struct with padding. Place an item that requires
// everthing to be copied.
Fix issue with union placeholder on Intel compiler We have run into an issue with some Intel compilers where if a `union` contains a `struct` that has some padding for byte alignment, the value copy might skip over that padding even when the `union` contains a different type where those bytes are valid. This breaks the value copy of our `Variant` class. This is not a unique problem. We have seen the same thing in other compilers and already have a workaround for when this happens. The workaround creates a special struct that has no padding placed at the front of the `union`. The Intel compiler adds a fun twist in that this placeholder structure only works if the alignment is at least as high as the struct that follows it. To get around this problem, make the alignment of the placeholder `struct` at large as possible for the size of the `union`. It was taking too long to compile with a device. Redesign the placeholder to be simpler and compile faster.
2023-08-31 18:36:48 +00:00
SizedPlaceholder<$type_list(max_expanded), Ts...> Placeholder;
Add an entry to VariantUnion to help compiler copy structs I've been seeing errors in a nightly build that compiles for CUDA Pascal using GCC5. The issue is that one of the `ArrayHandleMultiplexer` tests is failing to copy an implicit array correctly. I think the problem is that in this test the first and second type of the `Variant` are the same size, but the first type has some padding in the middle whereas the second type does not. When using this second type, the values in the same position of the padding of the first type don't seem to be initialized properly in the kernel invocation. My nonexhaustive experiment shows that things work OK as long as the first type is large enough and has no fillers. Enforce this by adding an internal entry to the union that is completely full.
2023-03-28 20:32:25 +00:00
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
$for(param_index in range(max_expanded))\
T$(param_index) V$(param_index);
$endfor\
VariantUnionTD<T$(max_expanded), Ts...> Remaining;
Reduce the number of lines required to implement VariantUnion
2021-03-30 20:35:44 +00:00
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
VTK_M_DEVICE VariantUnionTD(vtkm::internal::NullType) { }
VariantUnionTD() = default;
};
template <$typename_list(max_expanded), typename... Ts>
union VariantUnionNTD<$type_list(max_expanded), Ts...>
{
Add an entry to VariantUnion to help compiler copy structs I've been seeing errors in a nightly build that compiles for CUDA Pascal using GCC5. The issue is that one of the `ArrayHandleMultiplexer` tests is failing to copy an implicit array correctly. I think the problem is that in this test the first and second type of the `Variant` are the same size, but the first type has some padding in the middle whereas the second type does not. When using this second type, the values in the same position of the padding of the first type don't seem to be initialized properly in the kernel invocation. My nonexhaustive experiment shows that things work OK as long as the first type is large enough and has no fillers. Enforce this by adding an internal entry to the union that is completely full.
2023-03-28 20:32:25 +00:00
// Work around issue where CUDA sometimes seems to miss initializing some struct members
// if another entry in the varient has a struct with padding. Place an item that requires
// everthing to be copied.
Fix issue with union placeholder on Intel compiler We have run into an issue with some Intel compilers where if a `union` contains a `struct` that has some padding for byte alignment, the value copy might skip over that padding even when the `union` contains a different type where those bytes are valid. This breaks the value copy of our `Variant` class. This is not a unique problem. We have seen the same thing in other compilers and already have a workaround for when this happens. The workaround creates a special struct that has no padding placed at the front of the `union`. The Intel compiler adds a fun twist in that this placeholder structure only works if the alignment is at least as high as the struct that follows it. To get around this problem, make the alignment of the placeholder `struct` at large as possible for the size of the `union`. It was taking too long to compile with a device. Redesign the placeholder to be simpler and compile faster.
2023-08-31 18:36:48 +00:00
SizedPlaceholder<$type_list(max_expanded), Ts...> Placeholder;
Add an entry to VariantUnion to help compiler copy structs I've been seeing errors in a nightly build that compiles for CUDA Pascal using GCC5. The issue is that one of the `ArrayHandleMultiplexer` tests is failing to copy an implicit array correctly. I think the problem is that in this test the first and second type of the `Variant` are the same size, but the first type has some padding in the middle whereas the second type does not. When using this second type, the values in the same position of the padding of the first type don't seem to be initialized properly in the kernel invocation. My nonexhaustive experiment shows that things work OK as long as the first type is large enough and has no fillers. Enforce this by adding an internal entry to the union that is completely full.
2023-03-28 20:32:25 +00:00
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
$for(param_index in range(max_expanded))\
T$(param_index) V$(param_index);
$endfor\
VariantUnionNTD<T$(max_expanded), Ts...> Remaining;
Reduce the number of lines required to implement VariantUnion
2021-03-30 20:35:44 +00:00
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
VTK_M_DEVICE VariantUnionNTD(vtkm::internal::NullType) { }
VariantUnionNTD() = default;
VTK_M_DEVICE ~VariantUnionNTD() { }
};
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
//clang-format on
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
template <bool TrivialConstructor, typename... Ts>
struct VariantUnionFinder;
template <typename... Ts>
struct VariantUnionFinder<true, Ts...>
{
using type = VariantUnionTD<Ts...>;
};
template <typename... Ts>
struct VariantUnionFinder<false, Ts...>
{
using type = VariantUnionNTD<Ts...>;
};
template <typename... Ts>
using VariantUnion =
typename VariantUnionFinder<AllTriviallyDestructible<Ts...>::value, Ts...>::type;
// --------------------------------------------------------------------------------
// Methods to get values out of the variant union
template <vtkm::IdComponent I, typename UnionType>
struct VariantUnionGetImpl;
$for(param_index in range(max_expanded))\
template <typename UnionType>
struct VariantUnionGetImpl<$(param_index), UnionType>
{
Use specialized class instead of function overload for Variant::Get 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.
2021-03-23 19:30:55 +00:00
using ReturnType = decltype(std::declval<UnionType>().V$(param_index));
VTK_M_DEVICE static ReturnType& Get(UnionType& storage) noexcept
{
return storage.V$(param_index);
}
VTK_M_DEVICE static const ReturnType& Get(const UnionType& storage) noexcept
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
{
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
return storage.V$(param_index);
}
};
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
$endfor\
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
template <vtkm::IdComponent I, typename UnionType>
struct VariantUnionGetImpl
{
VTKM_STATIC_ASSERT(I >= $(max_expanded));
Use specialized class instead of function overload for Variant::Get 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.
2021-03-23 19:30:55 +00:00
using RecursiveGet = VariantUnionGetImpl<I - $(max_expanded), decltype(std::declval<UnionType&>().Remaining)>;
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
using ReturnType = typename RecursiveGet::ReturnType;
Use specialized class instead of function overload for Variant::Get 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.
2021-03-23 19:30:55 +00:00
VTK_M_DEVICE static ReturnType& Get(UnionType& storage) noexcept
{
return RecursiveGet::Get(storage.Remaining);
}
VTK_M_DEVICE static const ReturnType& Get(const UnionType& storage) noexcept
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
{
return RecursiveGet::Get(storage.Remaining);
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
}
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
};
template <vtkm::IdComponent I, typename UnionType>
Use specialized class instead of function overload for Variant::Get 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.
2021-03-23 19:30:55 +00:00
VTK_M_DEVICE auto VariantUnionGet(UnionType& storage) noexcept
-> decltype(VariantUnionGetImpl<I, typename std::decay<UnionType>::type>::Get(storage))&
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
{
Use specialized class instead of function overload for Variant::Get 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.
2021-03-23 19:30:55 +00:00
return VariantUnionGetImpl<I, typename std::decay<UnionType>::type>::Get(storage);
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
}
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
// --------------------------------------------------------------------------------
// Internal implementation of CastAndCall for Variant
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
template <std::size_t NumCases>
struct VariantCases
Reduce the number of lines required to implement Variant::CastAndCall
2021-03-30 21:22:38 +00:00
{
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
template <typename Functor, typename UnionType, typename... Args>
Turn off inlining of Variant::CastAndCall for HIP 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.
2022-03-28 17:27:00 +00:00
VTK_M_DEVICE static
#ifdef VTKM_HIP
// this is a temporary solution to improve Kokkos/HIP compile times for
// ConnectivityTracer in Rendering.
//
// This function currently gets inlined many times, which dramatically increases
// both compile time and the size of the resulting code-object
__attribute__((noinline))
#else
inline
#endif
auto CastAndCall(
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
vtkm::IdComponent index,
Functor&& f,
UnionType& storage,
Args&&... args) noexcept(noexcept(f(storage.V0, args...)))
-> decltype(f(storage.V0, args...))
{
VTKM_ASSERT((index >= 0) && (index < static_cast<vtkm::IdComponent>(NumCases)));
switch (index)
{
$for(param_index in range(max_expanded))\
case $(param_index):
// If you get a compile error here, it probably means that you have called
// Variant::CastAndCall with a functor that does not accept one of the types in the
// Variant. The functor you provide must be callable with all types in the Variant, not
// just the one that it currently holds.
return f(storage.V$(param_index), std::forward<Args>(args)...);
$endfor\
default:
return VariantCases<NumCases - $(max_expanded)>::template CastAndCall(
index - $(max_expanded), std::forward<Functor>(f), storage.Remaining, std::forward<Args>(args)...);
}
}
};
Reduce the number of lines required to implement Variant::CastAndCall
2021-03-30 21:22:38 +00:00
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
template<>
struct VariantCases<1>
Reduce the number of lines required to implement Variant::CastAndCall
2021-03-30 21:22:38 +00:00
{
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
template <typename Functor, typename UnionType, typename... Args>
VTK_M_DEVICE static inline auto CastAndCall(
vtkm::IdComponent index,
Functor&& f,
UnionType& storage,
Args&&... args) noexcept(noexcept(f(storage.V0, args...)))
-> decltype(f(storage.V0, args...))
{
// Assume index is 0. Saves us some conditionals.
VTKM_ASSERT(index == 0);
(void)index;
return f(storage.V0, std::forward<Args>(args)...);
}
};
Reduce the number of lines required to implement Variant::CastAndCall
2021-03-30 21:22:38 +00:00
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
$for(case_index in range(2, max_expanded + 1))\
template<>
struct VariantCases<$(case_index)>
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
{
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
template <typename Functor, typename UnionType, typename... Args>
Turn off inlining of Variant::CastAndCall for HIP 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.
2022-03-28 17:27:00 +00:00
VTK_M_DEVICE static
#ifdef VTKM_HIP
// this is a temporary solution to improve Kokkos/HIP compile times for
// ConnectivityTracer in Rendering.
//
// This function currently gets inlined many times, which dramatically increases
// both compile time and the size of the resulting code-object
__attribute__((noinline))
#else
inline
#endif
auto CastAndCall(
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
vtkm::IdComponent index,
Functor&& f,
UnionType& storage,
Args&&... args) noexcept(noexcept(f(storage.V0, args...)))
-> decltype(f(storage.V0, args...))
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
{
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
// Assume index is 0. Saves us some conditionals.
VTKM_ASSERT((index >= 0) && (index < $(case_index)));
switch (index)
{
default:
$for(param_index in range(case_index))\
case $(param_index):
// If you get a compile error here, it probably means that you have called
// Variant::CastAndCall with a functor that does not accept one of the types in the
// Variant. The functor you provide must be callable with all types in the Variant, not
// just the one that it currently holds.
return f(storage.V$(param_index), std::forward<Args>(args)...);
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
$endfor\
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
}
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
}
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
};
$endfor
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
template <std::size_t UnionSize, typename Functor, typename UnionType, typename... Args>
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
VTK_M_DEVICE inline auto VariantCastAndCallImpl(
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
vtkm::IdComponent index,
Functor&& f,
Use a union in Variant for safe type punning 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.
2021-03-17 20:38:33 +00:00
UnionType& storage,
Args&&... args) noexcept(noexcept(f(storage.V0, args...)))
-> decltype(f(storage.V0, args...))
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
{
Modify Variant CastAndCall to have fewer cases in its switch 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.
2022-03-23 12:19:31 +00:00
return VariantCases<UnionSize>::CastAndCall(
index, std::forward<Functor>(f), storage, std::forward<Args>(args)...);
Use large case statements to CastAndCall variants Previously, templates were used in the implementation of CastAndCall to find the type and call the underlying function. The templates checked one type at a time. However, compilers were not always great at optimizing a 15-call deep stack with an if statement at each one. Instead, use a case statement in a single function block. This requires providing separate code for each number of types. Currently, up to 20 are created (with pyexpander). If there are more than that, then the template recurses.
2019-07-22 19:56:35 +00:00
}
}
}
Expose the Variant helper class For several versions, VTK-m has had a `Variant` templated class. This acts like a templated union where the object will store one of a list of types specified as the template arguments. (There are actually 2 versions for the control and execution environments, respectively.) Because this is a complex class that required several iterations to work through performance and compiler issues, `Variant` was placed in the `internal` namespace to avoid complications with backward compatibility. However, the class has been stable for a while, so let us expose this helpful tool for wider use.
2022-11-01 13:52:41 +00:00
} // vtkm::VTK_M_NAMESPACE::detail
Reference in New Issue Copy Permalink