First steps towards implementing execution par_unseq

[hkaiser]

This is related to #2271

[sithhell]

I'd like to leave omp out of the picture here since we'd require users to compile with -fopenmp then.

[sithhell]

What about other compilers, should we issue a warning?

[sithhell]

Would be nice to have some confidence if it really has the expected effects (better code gen) before pushing it further.

[hkaiser]

Would be nice to have some confidence if it really has the expected effects (better code gen) before pushing it further.

I agree, but how can we get confidence without actually trying out things?

[sithhell]

> Would be nice to have some confidence if it really has the expected effects (better code gen) before pushing it further. I agree, but how can we get confidence without actually trying out things?

Trying it out doesn't mean it has be merged ;)

[jeffhammond]

Summary

You can't use OpenMP simd (or for) with a != comparison for loop termination, i.e. the following is invalid (see below), at least as of OpenMP 4.5.

+#if defined(HPX_HAVE_OPENMP_SIMD)
 +#pragma omp simd
 +#endif
 +                for (/**/; it != end; ++it)
 +                {
 +                    f(it);
 +                }

OpenMP 5 is expected to fix this. I don't know the precise status of that proposal but can look if you want.

I recall that Intel 18 compilers do not object to != in an OpenMP for loop (haven't checked SIMD explicitly) but GCC 7 and Clang 5 do.

I would not expect a compiler to attempt to vectorize container accesses if a random access iterator is not supported...

Details

The relevant portions of the OpenMP 4.5 specification are:

• Section 2.8.1

The simd directive places restrictions on the structure of the associated for-loops. Specifically, all associated for-loops must have canonical loop form (Section 2.6 on page 53).

• Section 2.6

A loop has canonical loop form if it conforms to the following:
for (init-expr; test-expr; incr-expr) structured-block
...
test-expr One of the following:
var relational-op b
b relational-op var
...
relational-op One of the following:
<
<=
>
>=

[hkaiser]

@jeffhammond thanks for this information. This branch is really meant to be used for experimentation towards implementing par_unseq, and I admit that I don't have too much experience with this.

[jeffhammond]

-openmp-simd is deprecated (https://software.intel.com/en-us/node/693432). It was replaced by -qopenmp-simd in version 16 or 17.

I recommend that CMake test for -fopenmp-simd, then -qopenmp-simd then -openmp-simd. ICC supports many of the GCC flags for compatibility...

[hkaiser]

Ok, thanks.

[jeffhammond]

For the non-x86 code path, you may want to use __builtin_prefetch, which both GCC and Clang support.

[hkaiser]

We can do that, MSVC however supports _mm_prefetch only.

[jeffhammond]

@hkaiser These are important experiments, in part because the OpenMP standard working group recognizes that support for C++ in OpenMP is lacking. While 5.0 is pretty close to finished, your experience in implementing PSTL will be useful in identifying gaps that should be addressed in the next iteration.

I don't know what code you allow yourself to look at (due to licensing), but both RAJA and Intel PSTL may be useful. In particular, RAJA supports a bunch of different pragmas for persuading compilers to vectorize inner loops.

[msimberg]

Closing this since it's not actively being worked on, but if someone feels like picking this up again, feel free to do so!