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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
