[PATCH] D31417: [OpenMP] Add support for omp simd pragmas without runtime

Alexey Bataev via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Apr 6 08:56:36 PDT 2017


ABataev added inline comments.


================
Comment at: lib/CodeGen/CodeGenModule.cpp:122-123
     createOpenCLRuntime();
-  if (LangOpts.OpenMP)
+  if (LangOpts.OpenMP || LangOpts.OpenMPSimd)
     createOpenMPRuntime();
   if (LangOpts.CUDA)
----------------
I don't think you need to create OpenMP runtime support object if you're not going to use it (and you're not going to use it because you don't want to link it). You'd better create your own OMPSIMDRuntime class, that supports emission of the simd code only.


================
Comment at: lib/Parse/ParseOpenMP.cpp:174
+      case OMPD_target_teams_distribute_simd:
+        DKind = OMPD_simd;
+        break;
----------------
huntergr wrote:
> rengolin wrote:
> > I'd like @ABataev to confirm this is the right semantics.
> Yes, would be good. I don't think there's a formal spec for this feature, but it's possible that directives intended for a different target than the cpu shouldn't apply with this flag.
I don't think you need it here. Instead, you should keep an existing logic in Sema/Parsing code, but you need to create your own OpenMPRuntime support class, that supports only emission of simd part of the constructs.


================
Comment at: lib/Parse/ParseOpenMP.cpp:1047
+    // as the filter function will have switched the kind.
+    if (!getLangOpts().OpenMPSimd)
+      Diag(Tok, diag::err_omp_unknown_directive);
----------------
huntergr wrote:
> rengolin wrote:
> > What if it's really unknown, even to `-fopenmp-simd`?
> I did wonder about handling this case; I defaulted to ignoring it, since we are already filtering out other non-simd constructs.
> 
> If we do want to catch it, then I can think of two options: creating the diagnostic right before the filter switch (possibly messy), or adding a new enum value of OMPD_non_simd_construct (or a similar name) to represent constructs we recognize but don't want to handle and differentiate against a true unknown. I think the latter would be preferable.
Leave it as is, we still have to report errors, even in simd-only mode


https://reviews.llvm.org/D31417





More information about the cfe-commits mailing list