Page MenuHomePhabricator

Explicitly annotate loops we want to run thread-parallel

Authored by grosser on Nov 5 2014, 2:21 PM.



We introduces a new flag -polly-parallel and use it to annotate the for-nodes in
the isl ast that we want to execute thread parallel (e.g., using OpenMP). We
previously already emmitted openmp annotations, but we did this for various
kinds of parallel loops, including some which we can not run in parallel.

With this patch we now have three annotations:

  1. #pragma known-parallel [reduction]
  2. #pragma omp for
  3. #pragma simd


  1. loop has no loop carried dependences
  2. loop will be executed thread-parallel
  3. loop can possibly be vectorized

This patch introduces 1) and reduces the use of 2) to only the cases where we
know generate thread parallel code.

It is in preparation of openmp code generation in our isl backend.


  • We also have a command line option -enable-polly-openmp. This option controls the OpenMP code generation in CLooG. It will become an alias of -polly-parallel after the CLooG code generation has been dropped.

Diff Detail

Event Timeline

grosser updated this revision to Diff 15829.Nov 5 2014, 2:21 PM
grosser retitled this revision from to Explicitly annotate loops we want to run thread-parallel.
grosser updated this object.
grosser added a subscriber: Unknown Object (MLST).
jdoerfert accepted this revision.Nov 6 2014, 11:21 AM
jdoerfert edited edge metadata.

I'm fine with the current version but you can also integrate my comments if you like.


Naming convention here seems to be:


if a bool is return, thus maybe:


I usually prefere the variable name to be the cmd option without the "-" in camel case, but I don't feel that strong about it.


UseThreads should be first as it is the cheapest and we will have no overhead in case no parallel code is generated.

This revision is now accepted and ready to land.Nov 6 2014, 11:21 AM
grosser closed this revision.Nov 6 2014, 11:48 AM

Committed in r221479 with review comments addressed.