jdoerfert marked an inline comment as done.
jdoerfert added inline comments.


================
Comment at: clang/test/OpenMP/barrier_codegen.cpp:22
+// CLANGCG-NOT: readonly
+// IRBUILDER:      ; Function Attrs: nofree nosync nounwind readonly
+// IRBUILDER-NEXT: declare i32 @__kmpc_global_thread_num(%struct.ident_t*)
----------------
ABataev wrote:
> jdoerfert wrote:
> > ABataev wrote:
> > > Not sure about correct use of `nosync` and `readonly` attributes. OpenMP 
> > > runtime uses lazy initialization of the runtime library and when any 
> > > runtime function is called, the inner parts of the OpenMP runtime are 
> > > initialized automatically. It may use some sync primitives and may modify 
> > > memory, I assume. Same about `nofree`.
> > There are two versions of these functions, host and device. I assume host 
> > functions are not inlined but device functions might be. This is basically 
> > all the modes we support right now.
> > 
> > If we do not inline the function (host) we don't necessarily care what they 
> > do but what effect the user can expect.
> > The user can not expect to synchronize through `__kmpc_global_thread_num` 
> > calls in a defined way, thus `nosync`.
> > Similarly, from the users perspective there is no way to determine if 
> > something was written or freed, no matter how many of these calls I issue 
> > and under which control conditions, all I see is the number as a result. 
> > Thus, `readonly` and `nofree`. I believe `readnone` is even fine here but 
> > it might not work for the device version (see below) so I removed it.
> > 
> > If we do inline the function (device) we need to make sure the attributes 
> > are compatible with the inlined code to not cause UB. The code of 
> > `__kmpc_global_thread_num` at least does not write anything and only reads 
> > stuff (as far as I can tell).
> > 
> > Please correct me if I overlooked something. 
> But someone may try to inline the host-based runtime or try to use LTO with 
> it.
> The question is not about the user expectations but about the optimizations 
> which can be triggered with these attributes.
This is our runtime and we have supported and unsupported usage models.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69922



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

Reply via email to