Trivial relocation of c-v-ref-array types

[isidorostsa]

This PR is an addition to the earlier #6264

It allows peeling away type qualifiers to make sure that declaring type T as trivially relocatable will declare the following types too:

const T, volatile T, const volatile T, T&, T&&, T[], T[n]

[jenkins-cscs]

Can one of the admins verify this patch?

[hkaiser]

LGTM, thanks!

[isidorostsa]

LGTM, thanks!

Thanks for reviewing, I am surprised there is not a simpler way to specialize all versions of a type at once

[hkaiser]

LGTM, thanks!

Thanks for reviewing, I am surprised there is not a simpler way to specialize all versions of a type at once

Well, there is, to some extent. You could write:

    namespace detail {

        template <typename T>
        struct is_trivially_relocatable<T> : std::is_trivially_copyable<T>
        {
        };
    }

    template <typename T>
    struct is_trivially_relocatable<T> : detail::is_trivially_relocatable<std::decay_t<T>>
    {
    };

In this case the user type specializations (the macros) would have to to map onto hpx::detail::is_trivially_relocatable instead of hpx::is_trivially_relocatable. However I'm not sure if this is a good idea.

[isidorostsa]

Oh that looks a lot cleaner, but I agree we could do without two is_trivially_relocatable traits :P

Also just noting that std::decay_t would not work for this case because we want to transform T[n] -> T instead of T[n] -> T*

[hkaiser]

@isidorostsa so let's go ahead with it as is, should we?

[isidorostsa]

Let me add some tests first and I think we are good

[StellarBot]

Performance test report

HPX Performance

Comparison

BENCHMARK	FORK_JOIN_EXECUTOR	PARALLEL_EXECUTOR	SCHEDULER_EXECUTOR
For Each	(=)	??	-

Info

Property	Before	After
HPX Datetime	2023-05-10T12:07:53+00:00	2023-07-28T21:26:07+00:00
HPX Commit	dcb5415	0d4f47e
Datetime	2023-05-10T14:50:18.616050-05:00	2023-07-28T16:36:32.321990-05:00
Envfile
Clustername	rostam	rostam
Compiler	/opt/apps/llvm/13.0.1/bin/clang++ 13.0.1	/opt/apps/llvm/13.0.1/bin/clang++ 13.0.1
Hostname	medusa08.rostam.cct.lsu.edu	medusa08.rostam.cct.lsu.edu

Comparison

BENCHMARK	NO-EXECUTOR
Future Overhead - Create Thread Hierarchical - Latch	=

Info

Property	Before	After
HPX Datetime	2023-05-10T12:07:53+00:00	2023-07-28T21:26:07+00:00
HPX Commit	dcb5415	0d4f47e
Datetime	2023-05-10T14:52:35.047119-05:00	2023-07-28T16:38:47.858923-05:00
Envfile
Clustername	rostam	rostam
Compiler	/opt/apps/llvm/13.0.1/bin/clang++ 13.0.1	/opt/apps/llvm/13.0.1/bin/clang++ 13.0.1
Hostname	medusa08.rostam.cct.lsu.edu	medusa08.rostam.cct.lsu.edu

Comparison

BENCHMARK	FORK_JOIN_EXECUTOR_DEFAULT_FORK_JOIN_POLICY_ALLOCATOR	PARALLEL_EXECUTOR_DEFAULT_PARALLEL_POLICY_ALLOCATOR	SCHEDULER_EXECUTOR_DEFAULT_SCHEDULER_EXECUTOR_ALLOCATOR
Stream Benchmark - Add	=	(=)	(=)
Stream Benchmark - Scale	(=)	=	(=)
Stream Benchmark - Triad	(=)	(=)	(=)
Stream Benchmark - Copy	(=)	(=)	(=)

Info

Property	Before	After
HPX Datetime	2023-05-10T12:07:53+00:00	2023-07-28T21:26:07+00:00
HPX Commit	dcb5415	0d4f47e
Datetime	2023-05-10T14:52:52.237641-05:00	2023-07-28T16:39:04.983307-05:00
Envfile
Clustername	rostam	rostam
Compiler	/opt/apps/llvm/13.0.1/bin/clang++ 13.0.1	/opt/apps/llvm/13.0.1/bin/clang++ 13.0.1
Hostname	medusa08.rostam.cct.lsu.edu	medusa08.rostam.cct.lsu.edu

Explanation of Symbols

Symbol	MEANING
=	No performance change (confidence interval within ±1%)
(=)	Probably no performance change (confidence interval within ±2%)
(+)/(-)	Very small performance improvement/degradation (≤1%)
+/-	Small performance improvement/degradation (≤5%)
++/--	Large performance improvement/degradation (≤10%)
+++/---	Very large performance improvement/degradation (>10%)
?	Probably no change, but quite large uncertainty (confidence interval with ±5%)
??	Unclear result, very large uncertainty (±10%)
???	Something unexpected…

[hkaiser]

@isidorostsa once you fix the clang-format issues, this seems to be good to go.

[isidorostsa]

@isidorostsa once you fix the clang-format issues, this seems to be good to go.

Will do, but let's discuss a bit on Thursday before merging

[hkaiser]

@isidorostsa there is still some clang-format problem, could you have a look, please?

[isidorostsa]

This will be integrated into #6314