================
@@ -317,6 +318,12 @@ def fdo_concurrent_to_openmp_EQ : Joined<["-"],
"fdo-concurrent-to-openmp=">,
HelpText<"Try to map `do concurrent` loops to OpenMP [none|host|device]">,
Values<"none, host, device">;
+def fimplicit_default_mapper_allocatable_members : Flag<["-"],
"fimplicit-default-mapper-allocatable-members">,
+ Group<f_Group>, HelpText<"Enable implicit allocatable member maps in
compiler-generated OpenMP default mappers">;
+def fno_implicit_default_mapper_allocatable_members : Flag<["-"],
"fno-implicit-default-mapper-allocatable-members">,
----------------
agozillon wrote:
While it does use the same functionality, I don't think we want to inhibit this
part of the compiler with this flag, primarily as do-concurrent is entirely
contingent on having the implicit mapping behaviour to work at all reasonably,
as there's no way to explicitly map anything in a do concurrent context (other
than enter/exit maps, but I am not sure that's a common thing to do for the
kind of applications that just want the extra parallelism on do concurrent) to
actually map the allocatable bits to device for it, and realistically maybe it
should also be doing so for pointers as I imagine they're not being mapped at
the moment.
@pranavb-ca @mjklemm what are your opinions on this, I don't mind either way, I
suppose it would allow users the ability to similarly opt out of allocatables
being mapped in do concurrent if they know what they're doing
https://github.com/llvm/llvm-project/pull/228748
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
