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

[Graham Hunter via Phabricator via cfe-commits]

huntergr abandoned this revision.
huntergr added a comment.

In D31417#1450587 , @xtian wrote:

> LGTM.  This provides a consistent behavior same as GCC and ICC w/ 
> -fopenmp-simd option. To answer, Kelvin's question. it is not directly tied 
> with "target".


Thanks for the review Xinmin, but as Alexey notes in the previous comment 
-fopenmp-simd support has already been committed -- I missed that comment 
earlier, but should have closed it then.

Apologies for the delay in implementing it Alexey, I just had too many other 
things to take care of at the time, and thanks for getting a better 
implementation in.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D31417/new/

https://reviews.llvm.org/D31417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Xinmin Tian via Phabricator via cfe-commits]

xtian accepted this revision.
xtian added a comment.
This revision is now accepted and ready to land.
Herald added subscribers: jdoerfert, jfb, guansong.

LGTM.  This provides a consistent behavior same as GCC and ICC w/ -fopenmp-simd 
option. To answer, Kelvin's question. it is not directly tied with "target".


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D31417/new/

https://reviews.llvm.org/D31417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added a comment.

I think we can abandon this one as support for -fopenmp-simd was committed 
already?


https://reviews.llvm.org/D31417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Hal Finkel via Phabricator via cfe-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D31417#886826, @huntergr wrote:

> In https://reviews.llvm.org/D31417#886441, @hfinkel wrote:
>
> > Is this still being worked on?
>
>
> Hi, yes it is. Sorry for the delay in posting new changes but priorities 
> shifted a bit and I had to work on something else for a while.


No problem.

> I do have a new version that's just about ready based on Alexey's idea. Simd 
> constructs work, and non-simd constructs just pass the code straight through; 
> combined constructs pose a bit of an issue, since they will have captured 
> stmts from non-simd directives as well. Some additional work will be needed 
> to handle that case. I'll post what I have after a bit of tidying for 
> comments and suggestions; it's possible that the mixed case could be dealt 
> with in another patch.

Splitting patches in this way is generally a good idea.

The other thing I'd like in this regard is some kind of preprocessor feature 
that my users can use to test whether OpenMP SIMD is supported. Enabling 
-fopenmp-simd won't define _OPENMP (at least I suspect that it shouldn't 
because there might not be a meaningful  to include).  Maybe we should 
make `#if __has_extension(openmp_simd)` work?


https://reviews.llvm.org/D31417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Graham Hunter via Phabricator via cfe-commits]

huntergr added a comment.

In https://reviews.llvm.org/D31417#886441, @hfinkel wrote:

> Is this still being worked on?


Hi, yes it is. Sorry for the delay in posting new changes but priorities 
shifted a bit and I had to work on something else for a while.

I do have a new version that's just about ready based on Alexey's idea. Simd 
constructs work, and non-simd constructs just pass the code straight through; 
combined constructs pose a bit of an issue, since they will have captured stmts 
from non-simd directives as well. Some additional work will be needed to handle 
that case. I'll post what I have after a bit of tidying for comments and 
suggestions; it's possible that the mixed case could be dealt with in another 
patch.


https://reviews.llvm.org/D31417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Hal Finkel via Phabricator via cfe-commits]

hfinkel added a comment.

Is this still being worked on?


https://reviews.llvm.org/D31417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: lib/Parse/ParseOpenMP.cpp:174
+  case OMPD_target_teams_distribute_simd:
+DKind = OMPD_simd;
+break;

huntergr wrote:
> ABataev wrote:
> > 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.
> Thanks for taking a look.
> 
> I tried this method first, but came to the conclusion it was too invasive. 
> I've now tried it a second time and came to the same conclusion.
> 
> The problem isn't in generating 'simd' or 'declare simd' from a custom 
> runtime class, but in generating everything else. Take a 'parallel for' 
> directive -- I have to generate something close to unmodified code, but 
> 'emitCommonOMPParallelDirective' in CGStmtOpenMP.cpp will only pass the loop 
> codegen lambda through to the runtime class's 'emitParallelOutlinedFunction', 
> which doesn't take the current CodeGenFunction as an argument (as it's 
> expected to create a new one). There doesn't seem to be a good way to look up 
> the CGF that the call will be made from.
> 
> You also won't get unmodified code in that instance anyway, as the loop is 
> generated by CodeGenFunction::EmitWorkSharingLoop, and a cancellation region 
> may be created; very little of this is under the control of the runtime 
> class, so it would need extensive modification to work.
> 
> So I'll switch to using a simd-only 'runtime' class, but I still think we 
> need to filter out non-simd directives before we get to codegen. Will post 
> updated patch soon.
1. I don't think it is a good idea to skip the checks for non-simd constructs 
in this new mode. I'd prefer to emit all diagnostics as usual. Thus, we can't 
simply translate all simd-related constructs into 'omp simd' only, as we're 
going to loose checks/diagnostics.
Keep in minв that you will need to update all diagnostics-specific tests to 
check that the same errors/warnings are emitted even in `-fopenmp-simd` mode.
2. You should not rewrite everything. You can do something like this:
file lib/CodeGen/CGStmt.cpp, function `void CodeGenFunction::EmitStmt(const 
Stmt *S)`
Insert before `switch (S->getStmtClass())`:
```
if (LangOpts.OpenMPSimd && isa(S)) {
  if (isOpenMPSimdDirective(S))
EmitOMPSimdDirective(S);
  else
EmitOMPInlinedDirective(S);
  return;
}
```
`EmitOMPSimdDirective(S)` shall emit the simd-specific code for all 
simd-related directives, while `EmitOMPInlinedDirective(S)` shall emit the code 
for all other constructs, ingnoring OpenMP directives.


https://reviews.llvm.org/D31417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Graham Hunter via Phabricator via cfe-commits]

huntergr added inline comments.



Comment at: lib/Parse/ParseOpenMP.cpp:174
+  case OMPD_target_teams_distribute_simd:
+DKind = OMPD_simd;
+break;

ABataev wrote:
> 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.
Thanks for taking a look.

I tried this method first, but came to the conclusion it was too invasive. I've 
now tried it a second time and came to the same conclusion.

The problem isn't in generating 'simd' or 'declare simd' from a custom runtime 
class, but in generating everything else. Take a 'parallel for' directive -- I 
have to generate something close to unmodified code, but 
'emitCommonOMPParallelDirective' in CGStmtOpenMP.cpp will only pass the loop 
codegen lambda through to the runtime class's 'emitParallelOutlinedFunction', 
which doesn't take the current CodeGenFunction as an argument (as it's expected 
to create a new one). There doesn't seem to be a good way to look up the CGF 
that the call will be made from.

You also won't get unmodified code in that instance anyway, as the loop is 
generated by CodeGenFunction::EmitWorkSharingLoop, and a cancellation region 
may be created; very little of this is under the control of the runtime class, 
so it would need extensive modification to work.

So I'll switch to using a simd-only 'runtime' class, but I still think we need 
to filter out non-simd directives before we get to codegen. Will post updated 
patch soon.


https://reviews.llvm.org/D31417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added inline comments.



Comment at: docs/ClangCommandLineReference.rst:1454
 
+.. option:: -fopenmp-simd, -fno-openmp-simd
+

I am not sure if it is target architecture specific or not.  If it is, should 
we be under the target flag instead?


https://reviews.llvm.org/D31417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Alexey Bataev via Phabricator via cfe-commits]

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

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

[Graham Hunter via Phabricator via cfe-commits]

huntergr added inline comments.



Comment at: lib/Parse/ParseOpenMP.cpp:174
+  case OMPD_target_teams_distribute_simd:
+DKind = OMPD_simd;
+break;

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.



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);

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.


https://reviews.llvm.org/D31417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Renato Golin via Phabricator via cfe-commits]

rengolin added a comment.

Hi Graham,

It looks much simpler now, thanks!

I'm ok with the change, but I'd like @ABataev to confirm that the semantics is 
the expected one for all cases and approve.

cheers,
--renato




Comment at: lib/Parse/ParseOpenMP.cpp:174
+  case OMPD_target_teams_distribute_simd:
+DKind = OMPD_simd;
+break;

I'd like @ABataev to confirm this is the right semantics.



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);

What if it's really unknown, even to `-fopenmp-simd`?


https://reviews.llvm.org/D31417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Graham Hunter via Phabricator via cfe-commits]

huntergr updated this revision to Diff 93841.
huntergr added a reviewer: kkwli0.
huntergr added a comment.

Changed to transform combined constructs to simd in ParseOpenMP.cpp instead of 
creating a new pragma handler. This also made it easier to add support for 
'declare simd': only needed the addition of a check for the option when code 
generating functions to enable it, so I've added a RUN line to test it in the 
'declare simd' codegen tests.


https://reviews.llvm.org/D31417

Files:
  docs/ClangCommandLineReference.rst
  docs/UsersManual.rst
  include/clang/Basic/LangOptions.def
  include/clang/Driver/Options.td
  lib/CodeGen/CodeGenFunction.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/Driver/ToolChains/Clang.cpp
  lib/Frontend/CompilerInvocation.cpp
  lib/Parse/ParseOpenMP.cpp
  lib/Parse/ParsePragma.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/declare_simd_codegen.cpp
  test/OpenMP/linking.c
  test/OpenMP/simd_only.c

Index: test/OpenMP/simd_only.c
===
--- /dev/null
+++ test/OpenMP/simd_only.c
@@ -0,0 +1,157 @@
+// RUN: %clang_cc1 -verify -fopenmp-simd -x c -triple aarch64-unknown-unknown -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -x c -triple x86_64-unknown-unknown -emit-llvm %s -o - | FileCheck %s
+// expected-no-diagnostics
+
+// CHECK-LABEL: @simd_plain
+// CHECK-LABEL: omp.inner.for.body:
+// CHECK: load float, float* %arrayidx{{.*}} !llvm.mem.parallel_loop_access
+// CHECK: load float, float* %arrayidx{{.*}} !llvm.mem.parallel_loop_access
+// CHECK: store float %{{.*}}, float* %arrayidx{{.*}} !llvm.mem.parallel_loop_access
+// CHECK: ret void
+void simd_plain(float *a, float *b, float *c, int N) {
+  #pragma omp simd
+  for (int i = 0; i < N; i += 2)
+a[i] = b[i] * c[i];
+}
+
+// CHECK-LABEL: @simd_safelen_clause
+// CHECK-NOT: !llvm.mem.parallel_loop_access
+// CHECK-LABEL: omp.inner.for.inc:
+// CHECK: br label %omp.inner.for.cond, !llvm.loop
+// CHECK: ret void
+void simd_safelen_clause(float *a, float *b, float *c, int N) {
+  #pragma omp simd safelen(4)
+  for (int i = 0; i < N; i += 2)
+a[i] = b[i] * c[i];
+}
+
+extern long long initial_val();
+
+// CHECK-LABEL: @simd_simdlen_and_linear_clause
+// CHECK: omp.inner.for.body:
+// CHECK: !llvm.mem.parallel_loop_access
+// CHECK: ret void
+void simd_simdlen_and_linear_clause(float *a, float *b, float *c, int N) {
+  long long lv = initial_val();
+  #pragma omp simd simdlen(2) linear(lv: 4)
+  for (int i = 0; i < N; ++i) {
+a[lv] = b[lv] * c[lv];
+lv += 4;
+  }
+}
+
+extern float gfloat;
+
+// CHECK-LABEL: @simd_aligned_and_private_clause
+// CHECK-LABEL: entry:
+// CHECK: %gfloat = alloca float, align 4
+// CHECK: store float 1.00e+00, float* @gfloat, align 4
+// CHECK-LABEL: omp.inner.for.body:
+// CHECK-NOT: @gfloat
+// CHECK: load{{.*}}!llvm.mem.parallel_loop_access
+// CHECK: store float {{.*}}, float* %gfloat, align 4, !llvm.mem.parallel_loop_access
+// CHECK: %[[FADD:add[0-9]+]] = fadd float %{{[0-9]+}}, 2.00e+00
+// CHECK: store float %[[FADD]], float* {{.*}}, align 4, !llvm.mem.parallel_loop_access
+// CHECK: ret void
+void simd_aligned_and_private_clause(float *a, float *b, float *c, int N) {
+  gfloat = 1.0f;
+  #pragma omp simd aligned(a:4) private(gfloat)
+  for (int i = 0; i < N; i += 2) {
+gfloat = b[i] * c[i];
+a[i] = gfloat + 2.0f;
+  }
+}
+
+// CHECK-LABEL: @simd_lastprivate_and_reduction_clause
+// CHECK-LABEL: entry:
+// CHECK: %[[SUMVAR:sum[0-9]+]] = alloca float, align 4
+// CHECK: store float 0.00e+00, float* %[[SUMVAR]], align 4
+// CHECK-LABEL: omp.inner.for.body
+// CHECK: %[[LOAD:[0-9]+]] = load float, float* %[[SUMVAR]], align 4, !llvm.mem.parallel_loop_access
+// CHECK: %[[FADD:add[0-9]+]] = fadd float %[[LOAD]], %mul{{.*}}
+// CHECK: store float %[[FADD]], float* %[[SUMVAR]], align 4, !llvm.mem.parallel_loop_access
+// CHECK: store i32{{.*}}, i32* %[[IDXVAR:idx[0-9]+]]
+// CHECK-LABEL: omp.inner.for.end:
+// CHECK-DAG: %[[TMP1:[0-9]+]] = load i32, i32* %[[IDXVAR]], align 4
+// CHECK-DAG: store i32 %[[TMP1]], i32* %idx, align 4
+// CHECK-DAG: %[[INITVAL:[0-9]+]] = load float, float* %sum, align 4
+// CHECK-DAG: %[[TMP2:[0-9]+]] = load float, float* %[[SUMVAR]], align 4
+// CHECK-DAG: %[[SUMMED:add[0-9]+]] = fadd float %[[INITVAL]], %[[TMP2]]
+// CHECK-DAG: store float %[[SUMMED]], float* %sum, align 4
+// CHECK-LABEL: simd.if.end:
+// CHECK: %[[OUTVAL:[0-9]+]] = load float, float* %sum, align 4
+// CHECK: %[[OUTADDR:[0-9]+]] = load float*, float** %a.addr, align 8
+// CHECK: store float %[[OUTVAL]], float* %[[OUTADDR]], align 4
+// CHECK: %[[RETIDX:[0-9]+]] = load i32, i32* %idx, align 4
+// CHECK: ret i32 %[[RETIDX]]
+int simd_lastprivate_and_reduction_clause(float *a, float *b, float *c, int N) {
+  float sum = 0.0f;
+  int idx;
+  #pragma omp simd lastprivate(idx) reduction(+:sum)
+  for (int i = 0; i < N; ++i) {
+sum += b[i] * c[i];
+idx = i * 2;
+  }

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

[Renato Golin via Phabricator via cfe-commits]

rengolin added a comment.

In https://reviews.llvm.org/D31417#713171, @huntergr wrote:

> The other alternative I thought of was to perform the filtering in 
> ParseOpenMP.cpp instead, but I need to figure out how to delete or skip 
> tokens there without cluttering up the rest of the OpenMP parsing.


That was my first thought, yes, but I'm not sure how invasive this could get.

> This feature comes from user requests, and basically matches the 
> functionality of other compilers (e.g. gcc).

Right, in this case, I think we have a stronger motivation to make that an 
integral part of the existing OpenMP parser.

cheers,
--renato


https://reviews.llvm.org/D31417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Graham Hunter via Phabricator via cfe-commits]

huntergr added a comment.

Hi Renato,

In https://reviews.llvm.org/D31417#713162, @rengolin wrote:

> I don't know much about Clang's machinery, but would it be possible to have 
> `-fopenmp-simd` generate the same handler, but with restrictions? I fear this 
> slight duplication could get considerably worse as we support more and more 
> "non-RT" OMP pragmas.


Sure, I can combine the handlers and switch behaviour within that if that's 
preferable. The other alternative I thought of was to perform the filtering in 
ParseOpenMP.cpp instead, but I need to figure out how to delete or skip tokens 
there without cluttering up the rest of the OpenMP parsing.

I'll come up with a new version with the combined handler tomorrow.

> Alternatively, if this is for testing purposes, we have another pragma which 
> does exactly the same thing as `omp simd`, which are the Clang vectorizer 
> pragmas (http://llvm.org/docs/Vectorizers.html#pragma-loop-hint-directives).

This feature comes from user requests, and basically matches the functionality 
of other compilers (e.g. gcc).

Thanks for the comments.

-Graham


https://reviews.llvm.org/D31417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Renato Golin via Phabricator via cfe-commits]

rengolin added a comment.

Hi Graham,

I don't know much about Clang's machinery, but would it be possible to have 
`-fopenmp-simd` generate the same handler, but with restrictions? I fear this 
slight duplication could get considerably worse as we support more and more 
"non-RT" OMP pragmas.

Alternatively, if this is for testing purposes, we have another pragma which 
does exactly the same thing as `omp simd`, which are the Clang vectorizer 
pragmas (http://llvm.org/docs/Vectorizers.html#pragma-loop-hint-directives).

cheers,
--renato


https://reviews.llvm.org/D31417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Graham Hunter via Phabricator via cfe-commits]

huntergr added a comment.

In https://reviews.llvm.org/D31417#712008, @fpetrogalli wrote:

> Hi Graham,
>
> thank you for working on this. I understand that you are gonna take care of 
> the CodeGen side of things for the new `-fopenmp-simd` option in a separate 
> patch?


CodeGen for 'simd' pragmas works fine with this patch. 'declare simd' doesn't 
quite work yet, but yes, I was planning to do that in a separate patch.

> I am asking because I expect that the tests in `test/OpenMP/declare_simd_*` 
> will give the same results when invoking clang with the new flag instead of 
> `-fopenmp`.

So 'isAllowedClauseForDirective' needs to be updated; at present, it just bails 
out immediately if the directive kind passed in is OMPD_declare_simd. The 
clauses for a 'declare simd' are handled a little differently in 
ParseOpenMP.cpp, and I need to look into why.

I mainly wanted feedback on the approach at this point, since the patch is 
pretty small and changes won't be too cumbersome.


https://reviews.llvm.org/D31417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Francesco Petrogalli via Phabricator via cfe-commits]

fpetrogalli added a comment.

Hi Graham,

thank you for working on this. I understand that you are gonna take care of the 
CodeGen side of things for the new `-fopenmp-simd` option in a separate patch?

I am asking because I expect that the tests in `test/OpenMP/declare_simd_*` 
will give the same results when invoking clang with the new flag instead of 
`-fopenmp`.

Thank you,

Francesco


https://reviews.llvm.org/D31417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Graham Hunter via Phabricator via cfe-commits]

huntergr created this revision.
Herald added a subscriber: rengolin.

Adds a new flag ('-fopenmp-simd') to clang which enables processing
of 'simd' and 'declare simd' pragmas without supporting the rest
of OpenMP.

The pragma handler will filter out directives and clauses which
aren't related to simd, and the driver will not add lib(g)omp to
the list of libraries to link.

Documentation updated to describe the new flag.


https://reviews.llvm.org/D31417

Files:
  docs/ClangCommandLineReference.rst
  docs/UsersManual.rst
  include/clang/Basic/LangOptions.def
  include/clang/Driver/Options.td
  lib/CodeGen/CodeGenModule.cpp
  lib/Driver/ToolChains/Clang.cpp
  lib/Frontend/CompilerInvocation.cpp
  lib/Parse/ParsePragma.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/linking.c
  test/OpenMP/simd_only.c

Index: test/OpenMP/simd_only.c
===
--- /dev/null
+++ test/OpenMP/simd_only.c
@@ -0,0 +1,157 @@
+// RUN: %clang_cc1 -verify -fopenmp-simd -x c -triple aarch64-unknown-unknown -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -x c -triple x86_64-unknown-unknown -emit-llvm %s -o - | FileCheck %s
+// expected-no-diagnostics
+
+// CHECK-LABEL: @simd_plain
+// CHECK-LABEL: omp.inner.for.body:
+// CHECK: load float, float* %arrayidx{{.*}} !llvm.mem.parallel_loop_access
+// CHECK: load float, float* %arrayidx{{.*}} !llvm.mem.parallel_loop_access
+// CHECK: store float %{{.*}}, float* %arrayidx{{.*}} !llvm.mem.parallel_loop_access
+// CHECK: ret void
+void simd_plain(float *a, float *b, float *c, int N) {
+  #pragma omp simd
+  for (int i = 0; i < N; i += 2)
+a[i] = b[i] * c[i];
+}
+
+// CHECK-LABEL: @simd_safelen_clause
+// CHECK-NOT: !llvm.mem.parallel_loop_access
+// CHECK-LABEL: omp.inner.for.inc:
+// CHECK: br label %omp.inner.for.cond, !llvm.loop
+// CHECK: ret void
+void simd_safelen_clause(float *a, float *b, float *c, int N) {
+  #pragma omp simd safelen(4)
+  for (int i = 0; i < N; i += 2)
+a[i] = b[i] * c[i];
+}
+
+extern long long initial_val();
+
+// CHECK-LABEL: @simd_simdlen_and_linear_clause
+// CHECK: omp.inner.for.body:
+// CHECK: !llvm.mem.parallel_loop_access
+// CHECK: ret void
+void simd_simdlen_and_linear_clause(float *a, float *b, float *c, int N) {
+  long long lv = initial_val();
+  #pragma omp simd simdlen(2) linear(lv: 4)
+  for (int i = 0; i < N; ++i) {
+a[lv] = b[lv] * c[lv];
+lv += 4;
+  }
+}
+
+extern float gfloat;
+
+// CHECK-LABEL: @simd_aligned_and_private_clause
+// CHECK-LABEL: entry:
+// CHECK: %gfloat = alloca float, align 4
+// CHECK: store float 1.00e+00, float* @gfloat, align 4
+// CHECK-LABEL: omp.inner.for.body:
+// CHECK-NOT: @gfloat
+// CHECK: load{{.*}}!llvm.mem.parallel_loop_access
+// CHECK: store float {{.*}}, float* %gfloat, align 4, !llvm.mem.parallel_loop_access
+// CHECK: %[[FADD:add[0-9]+]] = fadd float %{{[0-9]+}}, 2.00e+00
+// CHECK: store float %[[FADD]], float* {{.*}}, align 4, !llvm.mem.parallel_loop_access
+// CHECK: ret void
+void simd_aligned_and_private_clause(float *a, float *b, float *c, int N) {
+  gfloat = 1.0f;
+  #pragma omp simd aligned(a:4) private(gfloat)
+  for (int i = 0; i < N; i += 2) {
+gfloat = b[i] * c[i];
+a[i] = gfloat + 2.0f;
+  }
+}
+
+// CHECK-LABEL: @simd_lastprivate_and_reduction_clause
+// CHECK-LABEL: entry:
+// CHECK: %[[SUMVAR:sum[0-9]+]] = alloca float, align 4
+// CHECK: store float 0.00e+00, float* %[[SUMVAR]], align 4
+// CHECK-LABEL: omp.inner.for.body
+// CHECK: %[[LOAD:[0-9]+]] = load float, float* %[[SUMVAR]], align 4, !llvm.mem.parallel_loop_access
+// CHECK: %[[FADD:add[0-9]+]] = fadd float %[[LOAD]], %mul{{.*}}
+// CHECK: store float %[[FADD]], float* %[[SUMVAR]], align 4, !llvm.mem.parallel_loop_access
+// CHECK: store i32{{.*}}, i32* %[[IDXVAR:idx[0-9]+]]
+// CHECK-LABEL: omp.inner.for.end:
+// CHECK-DAG: %[[TMP1:[0-9]+]] = load i32, i32* %[[IDXVAR]], align 4
+// CHECK-DAG: store i32 %[[TMP1]], i32* %idx, align 4
+// CHECK-DAG: %[[INITVAL:[0-9]+]] = load float, float* %sum, align 4
+// CHECK-DAG: %[[TMP2:[0-9]+]] = load float, float* %[[SUMVAR]], align 4
+// CHECK-DAG: %[[SUMMED:add[0-9]+]] = fadd float %[[INITVAL]], %[[TMP2]]
+// CHECK-DAG: store float %[[SUMMED]], float* %sum, align 4
+// CHECK-LABEL: simd.if.end:
+// CHECK: %[[OUTVAL:[0-9]+]] = load float, float* %sum, align 4
+// CHECK: %[[OUTADDR:[0-9]+]] = load float*, float** %a.addr, align 8
+// CHECK: store float %[[OUTVAL]], float* %[[OUTADDR]], align 4
+// CHECK: %[[RETIDX:[0-9]+]] = load i32, i32* %idx, align 4
+// CHECK: ret i32 %[[RETIDX]]
+int simd_lastprivate_and_reduction_clause(float *a, float *b, float *c, int N) {
+  float sum = 0.0f;
+  int idx;
+  #pragma omp simd lastprivate(idx) reduction(+:sum)
+  for (int i = 0; i < N; ++i) {
+sum += b[i] * c[i];
+idx = i * 2;
+  }
+
+  *a = sum;
+  return idx;
+}
+
+// CHECK-LABEL: @simd_collapse_clause
+// CHECK: omp.inner.for.body:
+// CHECK-NOT: