main

GGitHub[flang][cuda] Add support for cluster_block_index in cooperative groups (#169427)

e23328b4创建于 2025年11月25日历史提交

文件	最后提交记录	最后更新时间
Analysis	[NFC][flang] Introduce FortranObjectViewOpInterface. (#166841) This patch adds initial version of FortranObjectViewOpInterface that helps walking def-use chains containing "pass-through" operations (like fir.convert, etc.). The new interface is used in FIR AliasAnalysis to demonstrate potential usage (I know we have such walks elsewhere in Flang, but I am only changing FIR AliasAnalysis in this patch). This is an NFC change. I noticed that if I remove followBoxData code there are no failing LIT tests, but I decided to keep it in order to keep the change looking more like NFC. This change is a follow-up on the discussion in #164020: it is unclear if the FortranObjectViewOpInterface methods and their usage, as in this patch, apply to the ViewLike operations that use the core MLIR ViewLikeOpInterface. So this patch is the path towards simplifying Flang code while also enabling a future discussion about having such an interface in core MLIR.	9 个月前
Builder	[flang][cuda] Add support for cluster_block_index in cooperative groups (#169427)	8 个月前
CodeGen	[flang][debug] Make common blocks data extraction more robust. (#168752) Our current implementation for extracting information about common block required traversal of FIR which was not ideal but previously there was no other way to obtain that information. The [hl]fir.declare was extended in commit https://github.com/llvm/llvm-project/pull/155325 to include storage and storage_offset. This commit adds these operands in fircg.ext_declare and then use them in AddDebugInfoPass to create debug data for common blocks.	9 个月前
Dialect	[flang] Implement !DIR$ IVDEP directive (#133728) This directive tells the compiler to ignore vector dependencies in the following loop and it must be placed before a do loop. Sometimes the compiler may not have sufficient information to decide whether a particular loop is vectorizable due to potential dependencies between iterations and the directive is here to tell to the compiler that vectorization is safe with parallelAccesses metadata. This directive is also equivalent to #pragma clang loop assume(safety) in C++	9 个月前
HLFIR	[flang] Implement !DIR$ IVDEP directive (#133728) This directive tells the compiler to ignore vector dependencies in the following loop and it must be placed before a do loop. Sometimes the compiler may not have sufficient information to decide whether a particular loop is vectorizable due to potential dependencies between iterations and the directive is here to tell to the compiler that vectorization is safe with parallelAccesses metadata. This directive is also equivalent to #pragma clang loop assume(safety) in C++	9 个月前
OpenACC	[acc][flang] Implement acc interface for tracking type descriptors (#168982) FIR operations that use derived types need to have type descriptor globals available on device when offloading. Examples of this can be seen in CUFDeviceGlobal which ensures that such type descriptor uses work on device for CUF. Similarly, this is needed for OpenACC. This change introduces a new interface to the OpenACC dialect named IndirectGlobalAccessOpInterface which can be attached to operations that may result in generation of accesses that use type descriptor globals. This functionality is needed for the ACCImplicitDeclare pass that is coming in a follow-up change which implicitly ensures that all referenced globals are available in OpenACC compute contexts. The interface provides a getReferencedSymbols method that collects all global symbols referenced by an operation. When a symbol table is provided, the implementation for FIR recursively walks type descriptor globals to find all transitively referenced symbols. Note that alternately this could have been implemented in different ways: - Codegen could implicitly generate such type globals as needed by changing the technique that relies on populating them during lowering (eg generate them directly in gpu.module during codegen). - This interface could attach to types instead of operations for a potentially more conservative implementation which maps all type descriptors even if the underlying implementation using it won't necessarily need such mapping. The technique chosen here is consistent with CUFDeviceGlobal (which walks operations inside prepareImplicitDeviceGlobals) and avoids conservative mapping of all type descriptors.	9 个月前
OpenMP	[OpenMP][flang] Lowering of OpenMP custom reductions to MLIR (#168417) This patch add support for lowering of custom reductions to MLIR. It also enhances the capability of the pass to automatically mark functions as "declare target" by traversing custom reduction initializers and combiners.	8 个月前
Passes	[Flang][mlir] - Translation of delayed privatization for deferred target-tasks (#155348) This PR adds support for translation of the private clause on deferred target tasks - that is omp.target operations with the nowait clause. An offloading call for a deferred target-task is not blocking - the offloading (target-generating) host task continues its execution after issuing the offloading call. Therefore, the key problem we need to solve is to ensure that the data needed for private variables to be initialized in the target task persists even after the host task has completed. We do this in a new pass called PrepareForOMPOffloadPrivatizationPass. For a privatized variable that needs its host counterpart for initialization (such as the shape of the data from the descriptor when an allocatable is privatized or the value of the data when an allocatable is firstprivatized), - the pass allocates memory on the heap. - it then initializes this memory by using the init and copy (for firstprivate) regions of the corresponding omp::PrivateClauseOp. - Finally the memory allocated on the heap is freed using the dealloc region of the same omp::PrivateClauseOp instance. This step is not straightforward though, because we cannot simply free the memory that's going to be used by another thread without any synchronization. So, for deallocation, we create a omp.task after the omp.target and synchronize the two with a dummy dependency (using the depend clause). In this newly created omp.task we do the deallocation.	9 个月前
Support	[flang] Fix build on different of cores from #164630 (#164841) Normally fix incorrect linking introduced in [#161179](https://github.com/llvm/llvm-project/pull/161179) with build in parallel.	9 个月前
Transforms	[flang][cuda] Extract element count computation into helper function (#168937) This patch extracts the common logic for computing array element counts from shape operands into a reusable helper function in CUFCommon.	9 个月前
.clang-format	[flang] [LLVMify F18] Compiler module folders should have capitalised names (flang-compiler/f18#980) This patch renames the modules in f18 to use a capital letter in the module name Signed-off-by: Caroline Concatto <caroline.concatto@arm.com> Original-commit: flang-compiler/f18@d2eb7a1c443d1539ef12b6f027074a0eb15b1ea0 Reviewed-on: https://github.com/flang-compiler/f18/pull/980	6 年前
.clang-tidy	Revert "[fir] Update clang-tidy for the Optimizer directory" This reverts commit edec659f480f02642461cebd422ab35152cdfd23.	4 年前
CMakeLists.txt	[flang][acc] Implement MappableType interfaces for fir.box and fir.array (#122495) The newly introduced MappableType interface in acc dialect was primarily intended to allow variables with non-materialized storage to be used in acc data clauses (previously everything was required to be pointer-like). One motivator for this was fir.box since it is possible to be passed to functions without a wrapping fir.ref and also it can be generated directly via operations like fir.embox - and unlike other variable representations in FIR, the underlying storage for it does not get materialized until LLVM codegen. The new interface is being attached to both fir.box and fir.array. Strictly speaking, attaching to the latter is primarily for consistency since the MappableType interface requires implementation of utilities to compute byte size - and it made sense that a fir.box<fir.array<10xi32>> and fir.array<10xi32> would have a consistently computable size. This decision may be revisited as MappableType interface evolves. The new interface attachments are made in a new library named FIROpenACCSupport. The reason for this is to avoid circular dependencies since the implementation of this library is reusing code from lowering of OpenACC. More specifically, the types are defined in FIRDialect and FortranLower depends on it. Thus we cannot attach these interfaces in FIRDialect.	1 年前