Tim Prince wrote:
On 8/29/2013 2:20 PM, Tobias Burnus wrote:
As far as I gathered, Cilk+'s pragmas and OpenMP'pragmas are supposed
to be handled identically. (I think there were some differences but
they got resolved by changing Cilk+.) There are some Cilk+ branches,
which aim at consolidating the effort with OpenMP. Actually, some
Cilk+ patches has been submitted for inclusion - thus, expect more
for this. (The submitted patches do not include SIMD as far as I
know. The branches do support it.)
There are distinctions in Intel compilers between Cilk(tm) Plus and
OpenMP 4.0. For example, Cilk(tm) Plus expects use of simd
firstprivate lastprivate where appropriate, while OpenMP 4.0 doesn't
support those clauses, and depends on the compiler recognizing those
cases of omp simd private.
What I recall was some discussion of about data dependency implications
of #pragma simd annotated and #pragma omp simd loops, which was resolved
by clarifying Cilk Plus to match OpenMP's definition. As long as they
have a very similar semantics and only only diverge at minor cases, they
can be represented internally in the same way - possibly even with
restricting special cases to the front end. (If not, one has to add some
special handling for those cases which diverge.)
PS: Regarding SIMD, in GCC 4.9 itself, some basic support has already
been merged a few days ago. However, it is not yet accessible from
user code (no front-end support) and I have the impression the
information is not yet used for optimization. But expect soon some
support (possibly something like #pragma simd, #pragma vector for
C/C++ and usage for DO CONCURRENT in Fortran) - but I don't know
which pragma and when the support will be added.
DO CONCURRENT needs a more satisfactory way to invoke omp parallel. A
limited facility (beyond current auto-parallelization) would not
appear in ifort until next year. It seems too difficult to cover all
possibilities. Auto-vectorization works well already (in gfortran,
for example).
Well, it is still useful to convey the information that the loop is
independent to the compiler's middle end; not in all cases the compiler
can deduce this automatically. That's what I intent to add for gfortran,
using the middle-end support at
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01619.html
Going parallel beyond vectorization is more tricky as the user might or
might not intent that "do concurrent" uses more than a single core.
Additionally, OpenMP already provides to express this (with additional
clauses), which is outside the language but more flexible and widely
used. Still, one might consider to turn them automatically
(-fdo-concurrent=openmp?) into OpenMP parallelization - but it is not
clear when to go (!$omp) parallel in this case. Given the overhead of
creating a new thread, doing this automatically is problematic and might
not be better than autoparallelization (which typically does not help much).
Talking about Cilk Plus: The latest "#pragma simd" patch (submitted for
the 4.9 trunk) is available at
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01626.html - when it is in,
it might be an alternative (under C/C++) for "#pragma omp simd" on the
development version of GCC 4.9. (At least until the OpenMPv4 is merged.)
(Cilk Plus - and hence #pragma simd - requires the option -fcilkplus for
compilation, which this patch also adds.)
Tobias
