[PATCH] D80240: [OPENMP50]Initial codegen for 'affinity' clauses.

Johannes Doerfert via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri May 29 14:14:20 PDT 2020


jdoerfert accepted this revision.
jdoerfert added subscribers: jhuber6, clementval, fghanim, DavidTruby.
jdoerfert added a comment.
This revision is now accepted and ready to land.

LGTM. Let's wait until D80222 <https://reviews.llvm.org/D80222> landed :)



================
Comment at: clang/lib/CodeGen/CGOpenMPRuntime.h:470
+  /// } kmp_task_affinity_info_t;
+  QualType KmpTaskAffinityInfoTy;
   /// struct kmp_dim {  // loop bounds info casted to kmp_int64
----------------
jdoerfert wrote:
> We really need to move these into OMPKinds.def as well. Not in this patch but soon.
Just a comment, not necessarily related to this review:
@clementval @DavidTruby @fghanim @jhuber6
We want to have all "internal" struct definitions in OMPKinds.def (as we have now), but also build boilerplate code for each of them once we use TableGen. We want to build a `class STRUCT_TY` which offers to create a local/global struct value, inspect the members, modify the members, create the IR type for it, etc.


================
Comment at: clang/test/OpenMP/task_affinity_codegen.cpp:54
+  // kmp_task_affinity_info_t affs[<num_elem>];
+  // CHECK: [[AFFS_ADDR:%.+]] = alloca %struct.kmp_task_affinity_info_t, i64 [[NUM_ELEMS]],
+  // store i64 %21, i64* %__vla_expr0, align 8
----------------
ABataev wrote:
> jdoerfert wrote:
> > I'm not so sure about dynamic allocas (without stack save/restore). If this happens in a loop we can run into problems fast, right?
> There are stack saves and restores for this alloca, see the calls of `@llvm.stacksave()` and `@llvm.stackrestore()`
Right, missed them. Thx.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80240





More information about the llvm-commits mailing list