en Copyright 2015 Java http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/OpenMP/irbuilder_nested_parallel_for.c#532dc62b [OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC)This adds -no-opaque-pointers to clang tests whose output willchange when opaque pointers are enabled by default. This isintended to be part of the migration approach described inhttps://discourse.llvm.org/t/enabling-opaque-pointers-by-default/61322/9.The patch has been produced by replacing %clang_cc1 with%clang_cc1 -no-opaque-pointers for tests that fail with opaquepointers enabled. Worth noting that this doesn't cover all tests,there's a remaining ~40 tests not using %clang_cc1 that will needa followup change.Differential Revision: https://reviews.llvm.org/D123115 List of files: /llvm-project-15.0.7/clang/test/OpenMP/irbuilder_nested_parallel_for.c Thu, 07 Apr 2022 10:03:55 +0000 Nikita Popov <npopov@redhat.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/OpenMP/irbuilder_nested_parallel_for.c#87ec6f41 [OpenMPIRBuilder] Allocate temporary at the correct block in a nested parallelThe OpenMPIRBuilder has a bug. Specifically, suppose you have two nested openmp parallel regions (writing with MLIR for ease)```omp.parallel { %a = ... omp.parallel { use(%a) }}```As OpenMP only permits pointer-like inputs, the builder will wrap all of the inputs into a stack allocation, and then pass thisallocation to the inner parallel. For example, we would want to get something like the following:```omp.parallel { %a = ... %tmp = alloc store %tmp[] = %a kmpc_fork(outlined, %tmp)}```However, in practice, this is not what currently occurs in the context of nested parallel regions. Specifically to the OpenMPIRBuilder,the entirety of the function (at the LLVM level) is currently inlined with blocks marking the corresponding start and end of eachregion.```entry: ...parallel1: %a = ... ...parallel2: use(%a) ...endparallel2: ...endparallel1: ...```When the allocation is inserted, it presently inserted into the parent of the entire function (e.g. entry) rather than the parentallocation scope to the function being outlined. If we were outlining parallel2, the corresponding alloca location would be parallel1.This causes a variety of bugs, including https://github.com/llvm/llvm-project/issues/54165 as one example.This PR allows the stack allocation to be created at the correct allocation block, and thus remedies such issues.Reviewed By: jdoerfertDifferential Revision: https://reviews.llvm.org/D121061 List of files: /llvm-project-15.0.7/clang/test/OpenMP/irbuilder_nested_parallel_for.c Sat, 05 Mar 2022 23:04:19 +0000 William S. Moses <gh@wsmoses.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/OpenMP/irbuilder_nested_parallel_for.c#a66f7769 [OpenMPIRBuilder] Implement static-chunked workshare-loop schedules.Add applyStaticChunkedWorkshareLoop method implementing static schedule when chunk-size is specified. Unlike a static schedule without chunk-size (where chunk-size is chosen by the runtime such that each thread receives one chunk), we need two nested loops: one for looping over the iterations of a chunk, and a second for looping over all chunks assigned to the threads.This patch includes the following related changes: * Adapt applyWorkshareLoop to triage between the schedule types, now possible since all schedules have been implemented. The default schedule is assumed to be non-chunked static, as without OpenMPIRBuilder. * Remove the chunk parameter from applyStaticWorkshareLoop, it is ignored by the runtime. Change the value for the value passed to the init function to 0, as without OpenMPIRBuilder. * Refactor CanonicalLoopInfo::setTripCount and CanonicalLoopInfo::mapIndVar as used by both, applyStaticWorkshareLoop and applyStaticChunkedWorkshareLoop. * Enable Clang to use the OpenMPIRBuilder in the presence of the schedule clause.Differential Revision: https://reviews.llvm.org/D114413 List of files: /llvm-project-15.0.7/clang/test/OpenMP/irbuilder_nested_parallel_for.c Fri, 25 Feb 2022 23:44:14 +0000 Michael Kruse <llvm-project@meinersbur.de> http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/OpenMP/irbuilder_nested_parallel_for.c#7cb4c261 [OMPIRBuilder] Generate aggregate argument for parallel region outlined functionsSummary:This patch modifies code generation in OpenMPIRBuilder to pass argumentsto the parallel region outlined function in an aggregate (struct),besides the global_tid and bound_tid arguments. It depends on theupdated CodeExtractor (see D96854) for support. It mirrors functionalityof Clang codegen (see D102107).Differential Revision: https://reviews.llvm.org/D110114 List of files: /llvm-project-15.0.7/clang/test/OpenMP/irbuilder_nested_parallel_for.c Wed, 26 Jan 2022 01:31:35 +0000 Giorgis Georgakoudis <georgakoudis1@llnl.gov> http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/OpenMP/irbuilder_nested_parallel_for.c#df729e2b [OpenMP] Overhaul `declare target` handlingThis patch fixes various issues with our prior `declare target` handlingand extends it to support `omp begin declare target` as well.This started with PR49649 in mind, trying to provide a way for users toavoid the "ref" global use introduced for globals with internal linkage.From there it went down the rabbit hole, e.g., all variables, even`nohost` ones, were emitted into the device code so it was impossible todetermine if "ref" was needed late in the game (based on the name only).To make it really useful, `begin declare target` was needed as it cancarry the `device_type`. Not emitting variables eagerly had a rippleeffect. Finally, the precedence of the (explicit) declare target listitems needed to be taken into account, that meant we cannot just lookfor any declare target attribute to make a decision. This caused thehandling of functions to require fixup as well.I tried to clean up things while I was at it, e.g., we should not "parsedeclarations and defintions" as part of OpenMP parsing, this will alwaysbreak at some point. Instead, we keep track what region we are in andact on definitions and declarations instead, this is what we do fordeclare variant and other begin/end directives already.Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary.---Notes:The patch is larger than I hoped but it turns out that most changes doon their own lead to "inconsistent states", which seem less desirableoverall.After working through this I feel the standard should remove theexplicit declare target forms as the delayed emission is horrible.That said, while we delay things anyway, it seems to me we check toooften for the current status even though that is often not sufficient toact upon. There seems to be a lot of duplication that can probably betrimmed down. Eagerly emitting some things seems pretty weak as anargument to keep so much logic around.---Reviewed By: ABataevDifferential Revision: https://reviews.llvm.org/D101030 List of files: /llvm-project-15.0.7/clang/test/OpenMP/irbuilder_nested_parallel_for.c Thu, 22 Apr 2021 05:57:28 +0000 Johannes Doerfert <johannes@jdoerfert.de> http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/OpenMP/irbuilder_nested_parallel_for.c#b1191206 [clang][OpenMP] Use OpenMPIRBuilder for workshare loops.Initial support for using the OpenMPIRBuilder by clang to generate loops using the OpenMPIRBuilder. This initial support is intentionally limited to: * Only the worksharing-loop directive. * Recognizes only the nowait clause. * No loop nests with more than one loop. * Untested with templates, exceptions. * Semantic checking left to the existing infrastructure.This patch introduces a new AST node, OMPCanonicalLoop, which becomes parent of any loop that has to adheres to the restrictions as specified by the OpenMP standard. These restrictions allow OMPCanonicalLoop to provide the following additional information that depends on base language semantics: * The distance function: How many loop iterations there will be before entering the loop nest. * The loop variable function: Conversion from a logical iteration number to the loop variable.These allow the OpenMPIRBuilder to act solely using logical iteration numbers without needing to be concerned with iterator semantics between calling the distance function and determining what the value of the loop variable ought to be. Any OpenMP logical should be done by the OpenMPIRBuilder such that it can be reused MLIR OpenMP dialect and thus by flang.The distance and loop variable function are implemented using lambdas (or more exactly: CapturedStmt because lambda implementation is more interviewed with the parser). It is up to the OpenMPIRBuilder how they are called which depends on what is done with the loop. By default, these are emitted as outlined functions but we might think about emitting them inline as the OpenMPRuntime does.For compatibility with the current OpenMP implementation, even though not necessary for the OpenMPIRBuilder, OMPCanonicalLoop can still be nested within OMPLoopDirectives' CapturedStmt. Although OMPCanonicalLoop's are not currently generated when the OpenMPIRBuilder is not enabled, these can just be skipped when not using the OpenMPIRBuilder in case we don't want to make the AST dependent on the EnableOMPBuilder setting.Loop nests with more than one loop require support by the OpenMPIRBuilder (D93268). A simple implementation of non-rectangular loop nests would add another lambda function that returns whether a loop iteration of the rectangular overapproximation is also within its non-rectangular subset.Reviewed By: jdennyDifferential Revision: https://reviews.llvm.org/D94973 List of files: /llvm-project-15.0.7/clang/test/OpenMP/irbuilder_nested_parallel_for.c Wed, 03 Mar 2021 23:15:32 +0000 Michael Kruse <llvm-project@meinersbur.de> http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/OpenMP/irbuilder_nested_parallel_for.c#07c33487 [OpenMP][NFC] Update test check lines with new script version List of files: /llvm-project-15.0.7/clang/test/OpenMP/irbuilder_nested_parallel_for.c Fri, 14 Aug 2020 13:49:42 +0000 Johannes Doerfert <johannes@jdoerfert.de> http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/OpenMP/irbuilder_nested_parallel_for.c#ebad64df [OpenMP][FIX] Consistently use OpenMPIRBuilder if requestedWhen we use the OpenMPIRBuilder for the parallel region we need to alsouse it to get the thread ID (among other things) in the body. This isbecause CGOpenMPRuntime::getThreadID() andCGOpenMPRuntime::emitUpdateLocation implicitly assumes that if they arecalled from within a parallel region there is a certain structure to thecode and certain members of the OMPRegionInfo are initialized. It mightmake sense to initialize them even if we use the OpenMPIRBuilder but wewould preferably get rid of such state instead.Bug reported by Anchu Rajendran Sudhakumari.Depends on D82470.Reviewed By: anchu-rajendranDifferential Revision: https://reviews.llvm.org/D82822 List of files: /llvm-project-15.0.7/clang/test/OpenMP/irbuilder_nested_parallel_for.c Mon, 29 Jun 2020 18:14:46 +0000 Johannes Doerfert <johannes@jdoerfert.de>