mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-17 22:06:38 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/flang/lib/Optimizer/CodeGen/CodeGen.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

4217 lines
180 KiB
C++
Raw Normal View History

[fir] Add base of the FIR to LLVM IR pass This patch adds the base of the FIR to LLVM IR Dialect conversion pass. It currently can convert the following operations: - fir.global - fir.has_value - fir.address_of - fir.undefined This patch is part of the upstreaming effort from fir-dev branch. It does not cover all FIR operations in order to have small patches. Several patches will follow to convert other operations. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D112845
2021-10-29 23:20:50 +02:00
//===-- CodeGen.cpp -- bridge to lower to LLVM ----------------------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
//
// Coding style: https://mlir.llvm.org/getting_started/DeveloperGuide/
//
//===----------------------------------------------------------------------===//
#include "flang/Optimizer/CodeGen/CodeGen.h"
[MLIR] Update pass declarations to new autogenerated files The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow dropping the old infrastructure. Reviewed By: mehdi_amini, rriddle Differential Review: https://reviews.llvm.org/D132838
2022-08-31 10:16:29 +02:00
[Flang][OpenMP] Initial mapping of Fortran pointers and allocatables for target devices (#71766) This patch seeks to add an initial lowering for pointers and allocatable variables captured by implicit and explicit map in Flang OpenMP for Target operations that take map clauses e.g. Target, Target Update. Target Exit/Enter etc. Currently this is done by treating the type that lowers to a descriptor (allocatable/pointer/assumed shape) as a map of a record type (e.g. a structure) as that's effectively what descriptor types lower to in LLVM-IR and what they're represented as in the Fortran runtime (written in C/C++). The descriptor effectively lowers to a structure containing scalar and array elements that represent various aspects of the underlying data being mapped (lower bound, upper bound, extent being the main ones of interest in most cases) and a pointer to the allocated data. In this current iteration of the mapping we map the structure in it's entirety and then attach the underlying data pointer and map the data to the device, this allows most of the required data to be resident on the device for use. Currently we do not support the addendum (another block of pointer data), but it shouldn't be too difficult to extend this to support it. The MapInfoOp generation for descriptor types is primarily handled in an optimization pass, where it expands BoxType (descriptor types) map captures into two maps, one for the structure (scalar elements) and the other for the pointer data (base address) and links them in a Parent <-> Child relationship. The later lowering processes will then treat them as a conjoined structure with a pointer member map.
2024-02-05 18:45:07 +01:00
#include "flang/Optimizer/CodeGen/CodeGenOpenMP.h"
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
#include "flang/Optimizer/CodeGen/FIROpPatterns.h"
#include "flang/Optimizer/CodeGen/TypeConverter.h"
[fir] Add fir.select_case conversion The `fir.select_case` operation is converted to a if-then-else ladder. Conversion of `fir.select_case` operation with character is not implemented yet. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, mehdi_amini Differential Revision: https://reviews.llvm.org/D113484 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-11 15:00:18 +01:00
#include "flang/Optimizer/Dialect/FIRAttr.h"
[flang][NFC] Split CG dialect and the passes. (#135240) I am making a CG pass to depend on `FIROpenACCSupport` in #134346. This introduces a cyclic dependency between `FIROpenACCSupport` and `FIRCodeGen`. This patch splits `FIRCodeGen` into `FIRCodeGenDialect` (for FIR CG dialect definition) and `FIRCodeGen` (for the CG passes). Now, `FIROpenACCSupport` depends on `FIRCodeGenDialect`, and `FIRCodeGen` depends on `FIROpenACCSupport`.
2025-04-10 16:13:04 -07:00
#include "flang/Optimizer/Dialect/FIRCG/CGOps.h"
Reland "[flang] Set LLVM specific attributes to fir.call's of Fortran runtime. (#128093)" This change is inspired by a case in facerec benchmark, where performance of scalar code may improve by about 6%@aarch64 due to getting rid of redundant loads from Fortran descriptors. These descriptors are corresponding to subroutine local ALLOCATABLE, SAVE variables. The scalar loop nest in LocalMove subroutine contains call to Fortran runtime IO functions, and LLVM globals-aa analysis cannot prove that these calls do not modify the globalized descriptors with internal linkage. This patch sets and propagates llvm.memory_effects attribute for fir.call operations calling Fortran runtime functions. In particular, it tries to set the Other memory effect to NoModRef. The Other memory effect includes accesses to globals and captured pointers, so we cannot set it for functions taking Fortran descriptors with one exception for calls where the Fortran descriptor arguments are all null. As long as different calls to the same Fortran runtime function may have different attributes, I decided to attach the attributes to the calls rather than functions. Moreover, attaching the attributes to func.func will require propagating these attributes to llvm.func, which is not happening right now. In addition to llvm.memory_effects, the new pass sets llvm.nosync and llvm.nocallback attributes that may also help LLVM alias analysis (e.g. see #127707). These attributes are ignored currently. I will support them in LLVM IR dialect in a separate patch. I also added another pass for developers to be able to print declarations/calls of all Fortran runtime functions that are recognized by the attributes setting pass. It should help with maintenance of the LIT tests.
2025-02-24 09:27:48 -08:00
#include "flang/Optimizer/Dialect/FIRDialect.h"
[fir] Add base of the FIR to LLVM IR pass This patch adds the base of the FIR to LLVM IR Dialect conversion pass. It currently can convert the following operations: - fir.global - fir.has_value - fir.address_of - fir.undefined This patch is part of the upstreaming effort from fir-dev branch. It does not cover all FIR operations in order to have small patches. Several patches will follow to convert other operations. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D112845
2021-10-29 23:20:50 +02:00
#include "flang/Optimizer/Dialect/FIROps.h"
[flang] Moving common polymorphic code into utility files Differential revision: https://reviews.llvm.org/D145530
2023-03-07 16:09:23 -08:00
#include "flang/Optimizer/Dialect/FIRType.h"
[flang] Add struct passing target rewrite hooks and partial X86-64 impl (#74829) In the context of C/Fortran interoperability (BIND(C)), it is possible to give the VALUE attribute to a BIND(C) derived type dummy, which according to Fortran 2018 18.3.6 - 2. (4) implies that it must be passed like the equivalent C structure value. The way C structure value are passed is ABI dependent. LLVM does not implement the C struct ABI passing for LLVM aggregate type arguments. It is up to the front-end, like clang is doing, to split the struct into registers or pass the struct on the stack (llvm "byval") as required by the target ABI. So the logic for C struct passing sits in clang. Using it from flang requires setting up a lot of clang context and to bridge FIR/MLIR representation to clang AST representation for function signatures (in both directions). It is a non trivial task. See https://stackoverflow.com/questions/39438033/passing-structs-by-value-in-llvm-ir/75002581#75002581. Since BIND(C) struct are rather limited as opposed to generic C struct (e.g. no bit fields). It is easier to provide a limited implementation of it for the case that matter to Fortran. This patch: - Updates the generic target rewrite pass to keep track of both the new argument type and attributes. The motivation for this is to be able to tell if a previously marshalled argument is passed in memory (it is a C pointer), or if it is being passed on the stack (has the byval llvm attributes). - Adds an entry point in the target specific codegen to marshal struct arguments, and use it in the generic target rewrite pass. - Implements limited support for the X86-64 case. So far, the support allows telling if a struct must be passed in register or on the stack, and to deal with the stack case. The register case is left TODO in this patch. The X86-64 ABI implemented is the System V ABI for AMD64 version 1.0
2023-12-12 11:52:39 +01:00
#include "flang/Optimizer/Support/DataLayout.h"
[flang] Fail at link time if derived type descriptors were not generated Currently, code generation was creating weak symbols for derived type descriptor global it could not find in the current compilation unit. The rational is that: - the derived type descriptors of external module derived types are generated in the compilation unit that compiled the module so that the type descriptor address is uniquely associated with the type. - some types do not have derived type descriptors: the builtin derived types used to create derived type descriptors. The runtime knows about them and does not need them to accomplish the feat of describing themselves. Hence, all unresolved derived type descriptors in codegen cannot be assumed to be resolved at link time. However, this caused immense debugging pain when, for some reasons, derived type descriptor that should be generated were not. This caused random runtime failures instead of a much cleaner link time failure. Improve this situation by allowing codegen to detect the builtin derived types that have no derived type descriptors and requiring the other unresolved derived type descriptor to be resolved at link time. Also make derived type descriptor constant data since this was a TODO and makes the situation even cleaner. This requiring telling lowering which compiler created symbols can be placed in read only memory. I considered using PARAMETER, but I have mixed feeling using it since that would cause the initializer expressions of derived type descriptor to be invalid from a Fortran point of view since pointer targets cannot be parameters. I do not want to start misusing Fortran attributes, even if I think it is quite unlikely semantics would currently complain. I also do not want to rely on the fact that all object symbols with the CompilerCreated flags are currently constant data. This could easily change in the future and cause runtime bugs if lowering rely on this while the assumption is not loud and clear in semantics. Instead, add a ReadOnly symbol flag to tell lowering that a compiler generated symbol can be placed in read only memory. Differential Revision: https://reviews.llvm.org/D119555
2022-02-14 11:36:32 +01:00
#include "flang/Optimizer/Support/InternalNames.h"
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
#include "flang/Optimizer/Support/TypeCode.h"
[flang] Moving common polymorphic code into utility files Differential revision: https://reviews.llvm.org/D145530
2023-03-07 16:09:23 -08:00
#include "flang/Optimizer/Support/Utils.h"
[flang][cuda] Correctly allocate memory for descriptor load (#120164) CodeGen will allocate memory for a new descriptor on descriptor loads. CUDA Fortran local descriptor are allocated in managed memory by the runtime. The newly allocated storage for cuda descriptor must also be allocated through the runtime.
2024-12-16 19:12:05 -08:00
#include "flang/Runtime/CUDA/descriptor.h"
[flang][cuda] Allocate descriptor in managed memory when emboxing device memory (#120485) When emboxing memory that comes from CUFMemAlloc, we need to allocate the descriptor in manage memory as it might be passed to a kernel.
2024-12-18 18:20:45 -08:00
#include "flang/Runtime/CUDA/memory.h"
[Flang][NFC] Split runtime headers in preparation for cross-compilation. (#112188) Split some headers into headers for public and private declarations in preparation for #110217. Moving the runtime-private headers in runtime-private include directory will occur in #110298. * Do not use `sizeof(Descriptor)` in the compiler. The size of the descriptor is target-dependent while `sizeof(Descriptor)` is the size of the Descriptor for the host platform which might be too small when cross-compiling to a different platform. Another problem is that the emitted assembly ((cross-)compiling to the same target) is not identical between Flang's running on different systems. Moving the declaration of `class Descriptor` out of the included header will also reduce the amount of #included sources. * Do not use `sizeof(ArrayConstructorVector)` and `alignof(ArrayConstructorVector)` in the compiler. Same reason as with `Descriptor`. * Compute the descriptor's extra flags without instantiating a Descriptor. `Fortran::runtime::Descriptor` is defined in the runtime source, but not the compiler source. * Move `InquiryKeywordHashDecode` into runtime-private header. The function is defined in the runtime sources and trying to call it in the compiler would lead to a link-error. * Move allocator-kind magic numbers into common header. They are the only declarations out of `allocator-registry.h` in the compiler as well. This does not make Flang cross-compile ready yet, the main goal is to avoid transitive header dependencies from Flang to clang-rt. There are more assumptions that host platform is the same as the target platform.
2024-12-06 15:29:00 +01:00
#include "flang/Runtime/allocator-registry-consts.h"
#include "flang/Runtime/descriptor-consts.h"
[flang] Fail at link time if derived type descriptors were not generated Currently, code generation was creating weak symbols for derived type descriptor global it could not find in the current compilation unit. The rational is that: - the derived type descriptors of external module derived types are generated in the compilation unit that compiled the module so that the type descriptor address is uniquely associated with the type. - some types do not have derived type descriptors: the builtin derived types used to create derived type descriptors. The runtime knows about them and does not need them to accomplish the feat of describing themselves. Hence, all unresolved derived type descriptors in codegen cannot be assumed to be resolved at link time. However, this caused immense debugging pain when, for some reasons, derived type descriptor that should be generated were not. This caused random runtime failures instead of a much cleaner link time failure. Improve this situation by allowing codegen to detect the builtin derived types that have no derived type descriptors and requiring the other unresolved derived type descriptor to be resolved at link time. Also make derived type descriptor constant data since this was a TODO and makes the situation even cleaner. This requiring telling lowering which compiler created symbols can be placed in read only memory. I considered using PARAMETER, but I have mixed feeling using it since that would cause the initializer expressions of derived type descriptor to be invalid from a Fortran point of view since pointer targets cannot be parameters. I do not want to start misusing Fortran attributes, even if I think it is quite unlikely semantics would currently complain. I also do not want to rely on the fact that all object symbols with the CompilerCreated flags are currently constant data. This could easily change in the future and cause runtime bugs if lowering rely on this while the assumption is not loud and clear in semantics. Instead, add a ReadOnly symbol flag to tell lowering that a compiler generated symbol can be placed in read only memory. Differential Revision: https://reviews.llvm.org/D119555
2022-02-14 11:36:32 +01:00
#include "flang/Semantics/runtime-type-info.h"
[flang] Support arith::FastMathFlagsAttr for fir::CallOp. The main purpose of this patch is to propagate fastmath attribute to SimplifyIntrinsicsPass, so that the inline code can inherit the call operation's attributes. Even though I added translation of fastmath from fir::CallOp to LLVM::CallOp, there are no fastmath attributes in LLVM IR. It looks like the translation drops it. This will need additional commits. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D137602
2022-11-09 15:18:50 -08:00
#include "mlir/Conversion/ArithCommon/AttrToLLVMConverter.h"
[flang][mlir][arith] Fix flang build after dialect renaming Tested with `ninja check-flang`
2022-09-29 11:55:17 -04:00
#include "mlir/Conversion/ArithToLLVM/ArithToLLVM.h"
[flang] Use mlir complex dialect for supported operations This patch lowers the complex operations supported by the MLIR complex dialect to those operations rather than libm. When the math runtime flag is set to precise, libm lowering is used instead. Differential Revision: https://reviews.llvm.org/D135882
2022-10-24 12:42:29 +00:00
#include "mlir/Conversion/ComplexToLLVM/ComplexToLLVM.h"
#include "mlir/Conversion/ComplexToStandard/ComplexToStandard.h"
[mlir] Split out a new ControlFlow dialect from Standard This dialect is intended to model lower level/branch based control-flow constructs. The initial set of operations are: AssertOp, BranchOp, CondBranchOp, SwitchOp; all split out from the current standard dialect. See https://discourse.llvm.org/t/standard-dialect-the-final-chapter/6061 Differential Revision: https://reviews.llvm.org/D118966
2022-02-03 20:59:43 -08:00
#include "mlir/Conversion/ControlFlowToLLVM/ControlFlowToLLVM.h"
[mlir][NFC] Rename StandardToLLVM to FuncToLLVM The current StandardToLLVM conversion patterns only really handle the Func dialect. The pass itself adds patterns for Arithmetic/CFToLLVM, but those should be/will be split out in a followup. This commit focuses solely on being an NFC rename. Aside from the directory change, the pattern and pass creation API have been renamed: * populateStdToLLVMFuncOpConversionPattern -> populateFuncToLLVMFuncOpConversionPattern * populateStdToLLVMConversionPatterns -> populateFuncToLLVMConversionPatterns * createLowerToLLVMPass -> createConvertFuncToLLVMPass Differential Revision: https://reviews.llvm.org/D120778
2022-03-01 14:53:41 -08:00
#include "mlir/Conversion/FuncToLLVM/ConvertFuncToLLVM.h"
[fir] Add base of the FIR to LLVM IR pass This patch adds the base of the FIR to LLVM IR Dialect conversion pass. It currently can convert the following operations: - fir.global - fir.has_value - fir.address_of - fir.undefined This patch is part of the upstreaming effort from fir-dev branch. It does not cover all FIR operations in order to have small patches. Several patches will follow to convert other operations. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D112845
2021-10-29 23:20:50 +02:00
#include "mlir/Conversion/LLVMCommon/Pattern.h"
[flang] Lower integer exponentiation into math::IPowI. Differential Revision: https://reviews.llvm.org/D132770
2022-08-26 16:12:25 -07:00
#include "mlir/Conversion/MathToFuncs/MathToFuncs.h"
[flang] Lower Fortran math intrinsic operations into MLIR ops or libm calls. Added new -lower-math-early option that defaults to 'true' that matches the current math lowering scheme. If set to 'false', the intrinsic math operations will be lowered to MLIR operations, which should potentially enable more MLIR optimizations, or libm calls, if there is no corresponding MLIR operation exists or if "precise" mode is requested. The generated math MLIR operations are then converted to LLVM dialect during codegen phase. The -lower-math-early option is not exposed to users currently. I plan to get rid of the "early" lowering completely, when "late" lowering is robust enough to support all math intrinsics that are currently supported via pgmath. So "late" mode will become default and -lower-math-early option will not be needed. This will effectively eliminate the mandatory dependency on pgmath in Fortran lowering, but this is WIP. Differential Revision: https://reviews.llvm.org/D128385
2022-06-22 14:41:02 -07:00
#include "mlir/Conversion/MathToLLVM/MathToLLVM.h"
#include "mlir/Conversion/MathToLibm/MathToLibm.h"
[flang][AMDGPU] Convert math ops to AMD GPU library calls instead of libm calls (#99517) This patch invokes a pass when compiling for an AMDGPU target to lower math operations to AMD GPU library calls library calls instead of libm calls.
2024-09-10 09:48:55 -04:00
#include "mlir/Conversion/MathToROCDL/MathToROCDL.h"
[Flang] Add OpenMP Conversion patterns This patch adds the OpenMP conversion patterns to the FIR to LLVM dialect lowering pass in Codegen. Appropriate legalization conditions are also added. This ensures that a mix of FIR and OpenMP dialects can be lowered to LLVM and OpenMP dialects. Also adds two tests. This is part of the upstreaming effort from the fir-dev branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Reviewed By: clementval, peixin Differential Revision: https://reviews.llvm.org/D121793 Co-authored-by: Sourabh Singh Tomar <SourabhSingh.Tomar@amd.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2022-03-21 14:09:47 +00:00
#include "mlir/Conversion/OpenMPToLLVM/ConvertOpenMPToLLVM.h"
[flang] Add PowerPC vec_add, vec_and, vec_mul, vec_sub and vec_xor intrinsics Differential Revision: https://reviews.llvm.org/D151857
2023-05-29 16:10:12 -04:00
#include "mlir/Conversion/VectorToLLVM/ConvertVectorToLLVM.h"
[flang] Add fastmath attributes to complex arithmetic (#70690) Propagate fast math flags through complex number lowering (when lowering fir.*c directly to llvm floating point operations). The lowering path through the MLIR complex dialect is unchanged. This leads to a small improvement in spec2017 fotonik3d_r.
2023-10-31 16:15:13 +00:00
#include "mlir/Dialect/Arith/IR/Arith.h"
[flang] Add struct passing target rewrite hooks and partial X86-64 impl (#74829) In the context of C/Fortran interoperability (BIND(C)), it is possible to give the VALUE attribute to a BIND(C) derived type dummy, which according to Fortran 2018 18.3.6 - 2. (4) implies that it must be passed like the equivalent C structure value. The way C structure value are passed is ABI dependent. LLVM does not implement the C struct ABI passing for LLVM aggregate type arguments. It is up to the front-end, like clang is doing, to split the struct into registers or pass the struct on the stack (llvm "byval") as required by the target ABI. So the logic for C struct passing sits in clang. Using it from flang requires setting up a lot of clang context and to bridge FIR/MLIR representation to clang AST representation for function signatures (in both directions). It is a non trivial task. See https://stackoverflow.com/questions/39438033/passing-structs-by-value-in-llvm-ir/75002581#75002581. Since BIND(C) struct are rather limited as opposed to generic C struct (e.g. no bit fields). It is easier to provide a limited implementation of it for the case that matter to Fortran. This patch: - Updates the generic target rewrite pass to keep track of both the new argument type and attributes. The motivation for this is to be able to tell if a previously marshalled argument is passed in memory (it is a C pointer), or if it is being passed on the stack (has the byval llvm attributes). - Adds an entry point in the target specific codegen to marshal struct arguments, and use it in the generic target rewrite pass. - Implements limited support for the X86-64 case. So far, the support allows telling if a struct must be passed in register or on the stack, and to deal with the stack case. The register case is left TODO in this patch. The X86-64 ABI implemented is the System V ABI for AMD64 version 1.0
2023-12-12 11:52:39 +01:00
#include "mlir/Dialect/DLTI/DLTI.h"
[flang][cuda] Support malloc and free conversion in gpu module (#116112)
2024-11-13 17:09:38 -08:00
#include "mlir/Dialect/GPU/IR/GPUDialect.h"
[flang][NFC] Fix include style (#85655)
2024-03-18 11:17:32 -07:00
#include "mlir/Dialect/LLVMIR/LLVMAttrs.h"
[MLIR] Update pass declarations to new autogenerated files The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow dropping the old infrastructure. Reviewed By: mehdi_amini, rriddle Differential Review: https://reviews.llvm.org/D132838
2022-08-31 10:16:29 +02:00
#include "mlir/Dialect/LLVMIR/LLVMDialect.h"
[flang][cuda] Lower shared global to the correct NVVM address space (#131368) Global with the CUDA shared data attribute needs to be lowered to llvm globals with the correct address space (3). Address space is set from the `mlir::NVVM::NVVMMemorySpace::kSharedMemorySpace` enum from `mlir/Dialect/LLVMIR/NVVMDialect.h`
2025-03-14 15:28:32 -07:00
#include "mlir/Dialect/LLVMIR/NVVMDialect.h"
[flang] Add comdats to functions with linkonce linkage (#66516) This fixes a bug where functions generated by the MLIR Math dialect, for example ipowi, would fail to link with link.exe on Windows due to having linkonce linkage but no associated comdat. Adding the comdat on ELF also allows linkers to perform better garbage collection in the binary. Simply adding comdats to all functions with this linkage type should also cover future cases where linkonce or linkonce_odr functions might be necessary.
2023-09-19 15:00:04 +01:00
#include "mlir/Dialect/LLVMIR/Transforms/AddComdats.h"
[flang][openacc] Add missing piece to translate to LLVM IR dialect Add missing pieces to translate handle OpenACC dialect in the translation. Depends on D147825 Reviewed By: PeteSteinfeld, razvanlupusoru Differential Revision: https://reviews.llvm.org/D147828
2023-04-10 14:29:58 -07:00
#include "mlir/Dialect/OpenACC/OpenACC.h"
[MLIR] Update pass declarations to new autogenerated files The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow dropping the old infrastructure. Reviewed By: mehdi_amini, rriddle Differential Review: https://reviews.llvm.org/D132838
2022-08-31 10:16:29 +02:00
#include "mlir/Dialect/OpenMP/OpenMPDialect.h"
[fir] Add base of the FIR to LLVM IR pass This patch adds the base of the FIR to LLVM IR Dialect conversion pass. It currently can convert the following operations: - fir.global - fir.has_value - fir.address_of - fir.undefined This patch is part of the upstreaming effort from fir-dev branch. It does not cover all FIR operations in order to have small patches. Several patches will follow to convert other operations. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D112845
2021-10-29 23:20:50 +02:00
#include "mlir/IR/BuiltinTypes.h"
[fir] Add fir.insert_on_range conversion Convert fir.insert_on_range operation to corresponding llvm.insertvalue operations. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D112896
2021-11-04 10:36:00 +01:00
#include "mlir/IR/Matchers.h"
[fir] Add base of the FIR to LLVM IR pass This patch adds the base of the FIR to LLVM IR Dialect conversion pass. It currently can convert the following operations: - fir.global - fir.has_value - fir.address_of - fir.undefined This patch is part of the upstreaming effort from fir-dev branch. It does not cover all FIR operations in order to have small patches. Several patches will follow to convert other operations. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D112845
2021-10-29 23:20:50 +02:00
#include "mlir/Pass/Pass.h"
[flang] Lower integer exponentiation into math::IPowI. Differential Revision: https://reviews.llvm.org/D132770
2022-08-26 16:12:25 -07:00
#include "mlir/Pass/PassManager.h"
[Flang][MLIR] Add basic initial support for alloca and program address space handling in FIR->LLVMIR codegen (#77518) This is a slightly more slimmed down and up-to-date version of the older PR from here: https://reviews.llvm.org/D144203, written by @jsjodin, which has already under gone some review. This PR places allocas in the alloca address space specified by the provided data layout (default is 0 for all address spaces, unless explicitly specified by the layout), and then will cast these alloca's to the program address space if this address space is different from the allocation address space. For most architectures data layouts, this will be a no-op, as they have a flat address space. But in the case of AMDGPU it will result in allocas being placed in the correct address space (5, private), and then casted into the correct program address space (0, generic). This results in correct (partially, a follow up PR will be forthcoming soon) generation of allocations inside of device code. This PR is in addition to the work by @skatrak in this PR: https://github.com/llvm/llvm-project/pull/69599 and adds seperate and neccesary functionality of casting alloca's from their address space to the program address space, both are independent PRs, although there is some minor overlap e.g. this PR incorporates some of the useful helper functions from 69599, so whichever lands first will need a minor rebase. Co-author: jsjodin
2024-01-17 17:37:16 +01:00
#include "mlir/Target/LLVMIR/Import.h"
[flang] Update tco tool pipline and add translation to LLVM IR tco is a tool to test the FIR to LLVM IR pipeline of the Flang compiler. This patch update tco pipelines and adds the translation to LLVM IR. A simple test is added to make sure the tool is working with a simple FIR program. More tests will be upstream in follow up patch from the fir-dev branch. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski, schweitz, mehdi_amini Differential Revision: https://reviews.llvm.org/D117781 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
2022-01-24 14:14:49 +01:00
#include "mlir/Target/LLVMIR/ModuleTranslation.h"
[fir] Add base of the FIR to LLVM IR pass This patch adds the base of the FIR to LLVM IR Dialect conversion pass. It currently can convert the following operations: - fir.global - fir.has_value - fir.address_of - fir.undefined This patch is part of the upstreaming effort from fir-dev branch. It does not cover all FIR operations in order to have small patches. Several patches will follow to convert other operations. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D112845
2021-10-29 23:20:50 +02:00
#include "llvm/ADT/ArrayRef.h"
[flang] Handle fir.class pointer and allocatable in fir.dispatch code gen fir.dispatch code generation was not handling fir.class pointer and allocatable types. Update the code generation part to rertieve correctly the the type info from those types. Depends on D136426 Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D136429
2022-10-21 14:34:37 +02:00
#include "llvm/ADT/TypeSwitch.h"
[fir] Add base of the FIR to LLVM IR pass This patch adds the base of the FIR to LLVM IR Dialect conversion pass. It currently can convert the following operations: - fir.global - fir.has_value - fir.address_of - fir.undefined This patch is part of the upstreaming effort from fir-dev branch. It does not cover all FIR operations in order to have small patches. Several patches will follow to convert other operations. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D112845
2021-10-29 23:20:50 +02:00
[MLIR] Update pass declarations to new autogenerated files The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow dropping the old infrastructure. Reviewed By: mehdi_amini, rriddle Differential Review: https://reviews.llvm.org/D132838
2022-08-31 10:16:29 +02:00
namespace fir {
#define GEN_PASS_DEF_FIRTOLLVMLOWERING
#include "flang/Optimizer/CodeGen/CGPasses.h.inc"
} // namespace fir
[fir] Add base of the FIR to LLVM IR pass This patch adds the base of the FIR to LLVM IR Dialect conversion pass. It currently can convert the following operations: - fir.global - fir.has_value - fir.address_of - fir.undefined This patch is part of the upstreaming effort from fir-dev branch. It does not cover all FIR operations in order to have small patches. Several patches will follow to convert other operations. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D112845
2021-10-29 23:20:50 +02:00
#define DEBUG_TYPE "flang-codegen"
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
// TODO: This should really be recovered from the specified target.
static constexpr unsigned defaultAlign = 8;
[fir] Add fir.box_isarray, fir.box_isptr and fir.box_isalloc conversion. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113566 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-11 10:39:02 +01:00
/// `fir.box` attribute values as defined for CFI_attribute_t in
/// flang/ISO_Fortran_binding.h.
static constexpr unsigned kAttrPointer = CFI_attribute_pointer;
static constexpr unsigned kAttrAllocatable = CFI_attribute_allocatable;
[Flang][MLIR] Add basic initial support for alloca and program address space handling in FIR->LLVMIR codegen (#77518) This is a slightly more slimmed down and up-to-date version of the older PR from here: https://reviews.llvm.org/D144203, written by @jsjodin, which has already under gone some review. This PR places allocas in the alloca address space specified by the provided data layout (default is 0 for all address spaces, unless explicitly specified by the layout), and then will cast these alloca's to the program address space if this address space is different from the allocation address space. For most architectures data layouts, this will be a no-op, as they have a flat address space. But in the case of AMDGPU it will result in allocas being placed in the correct address space (5, private), and then casted into the correct program address space (0, generic). This results in correct (partially, a follow up PR will be forthcoming soon) generation of allocations inside of device code. This PR is in addition to the work by @skatrak in this PR: https://github.com/llvm/llvm-project/pull/69599 and adds seperate and neccesary functionality of casting alloca's from their address space to the program address space, both are independent PRs, although there is some minor overlap e.g. this PR incorporates some of the useful helper functions from 69599, so whichever lands first will need a minor rebase. Co-author: jsjodin
2024-01-17 17:37:16 +01:00
static inline mlir::Type getLlvmPtrType(mlir::MLIRContext *context,
unsigned addressSpace = 0) {
return mlir::LLVM::LLVMPointerType::get(context, addressSpace);
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
}
static inline mlir::Type getI8Type(mlir::MLIRContext *context) {
return mlir::IntegerType::get(context, 8);
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
}
[fir] Add !fir.alloca conversion Convert !fir.alloca into !llvm.alloca. This also contains a fix for verifyInType in FIROps.cpp, to make sure we can handle a !fir.ptr<!fir.array<?xN>>. Differential Revision: https://reviews.llvm.org/D113563 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-08 10:59:48 +00:00
static mlir::LLVM::ConstantOp
genConstantIndex(mlir::Location loc, mlir::Type ity,
mlir::ConversionPatternRewriter &rewriter,
std::int64_t offset) {
[flang] Revert changes (NFC)
2022-08-09 16:10:21 -04:00
auto cattr = rewriter.getI64IntegerAttr(offset);
return rewriter.create<mlir::LLVM::ConstantOp>(loc, ity, cattr);
[fir] Add !fir.alloca conversion Convert !fir.alloca into !llvm.alloca. This also contains a fix for verifyInType in FIROps.cpp, to make sure we can handle a !fir.ptr<!fir.array<?xN>>. Differential Revision: https://reviews.llvm.org/D113563 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-08 10:59:48 +00:00
}
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
static mlir::Block *createBlock(mlir::ConversionPatternRewriter &rewriter,
mlir::Block *insertBefore) {
[fir] Add fir.select_case conversion The `fir.select_case` operation is converted to a if-then-else ladder. Conversion of `fir.select_case` operation with character is not implemented yet. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, mehdi_amini Differential Revision: https://reviews.llvm.org/D113484 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-11 15:00:18 +01:00
assert(insertBefore && "expected valid insertion block");
return rewriter.createBlock(insertBefore->getParent(),
mlir::Region::iterator(insertBefore));
}
[flang] Normalize logical values during type conversions. Flang was missing value normalization for logical<->integer conversions which is required by Flang specification. The shrinking logical<->logical conversions were also incorrectly truncating the input. This change performs value normalization for all logical<->integer conversions and logical<->logical conversions between different kinds. Note that value normalization is not strictly required for logical(kind=k1)->logical(kind=k2) conversions when k1 < k2. Differential Revision: https://reviews.llvm.org/D147019
2023-03-27 19:28:36 -07:00
/// Extract constant from a value that must be the result of one of the
/// ConstantOp operations.
static int64_t getConstantIntValue(mlir::Value val) {
[flang][NFC] Unify getIfConstantIntValue helpers (#87633) There were different helpers for attempting to fetch compile time constants from MLIR: one in fir::getIntIfConstant and one in CodeGen. Unify the two.
2024-04-05 12:39:24 +01:00
if (auto constVal = fir::getIntIfConstant(val))
[flang] Normalize logical values during type conversions. Flang was missing value normalization for logical<->integer conversions which is required by Flang specification. The shrinking logical<->logical conversions were also incorrectly truncating the input. This change performs value normalization for all logical<->integer conversions and logical<->logical conversions between different kinds. Note that value normalization is not strictly required for logical(kind=k1)->logical(kind=k2) conversions when k1 < k2. Differential Revision: https://reviews.llvm.org/D147019
2023-03-27 19:28:36 -07:00
return *constVal;
[flang] Merge GEPs in substring fir.embox codegen When computing the base addresses of an array slice to make a descriptor, codegen generated two LLVM GEPs. The first to compute the address of the base character element, and a second one to compute the substring base inside that element. The previous code did not care about getting the result of the first GEP right: it used the base array LLVM type as the result type. This used to work when opaque pointer were not enabled (the actual GEP result type was probably applied in some later pass). But with opaque pointers, the second GEP ends-up computing an offset of len*<LLVM array type> instead of len*<character width>. A previous attempt to fix the issue was done in D129079, but it does not cover the cases where the array slice contains subcomponents before the substring (e.g: array(:)%char_field(5:10)). This patch fix the issue by computing the actual GEP result type in codegen. There is also enough knowledge now so that a single GEP can be generated instead of two. Differential Revision: https://reviews.llvm.org/D129481
2022-07-12 09:26:16 +02:00
fir::emitFatalError(val.getLoc(), "must be a constant");
}
[flang] Carry dynamic type in fir.rebox code generation Load the pointer of the dynamic type descriptor from the original box and update the destination descriptor with this pointer. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D136618
2022-10-24 20:42:31 +02:00
static unsigned getTypeDescFieldId(mlir::Type ty) {
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
auto isArray = mlir::isa<fir::SequenceType>(fir::dyn_cast_ptrOrBoxEleTy(ty));
[flang] Carry dynamic type in fir.rebox code generation Load the pointer of the dynamic type descriptor from the original box and update the destination descriptor with this pointer. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D136618
2022-10-24 20:42:31 +02:00
return isArray ? kOptTypePtrPosInBox : kDimsPosInBox;
}
[flang] Do not leave length parameters uninitialized in descriptor addendums (#81858) Descriptor addendum have a field to hold length parameters (currently only one). This field is currently never used because flang does not lowered derived types with length parameters. However, leaving it uninitialized is causing bugs in code like gFTL where the code is trying to sort POINTERs (see [1]). More precisely, it is an issue when two pointers should compare equal (same base address), because the uninitialized values in the addendum may differ depending on the "stack history" and optimization level. Always initialized the length parameters field in the addendum to zero. [1]: https://github.com/Goddard-Fortran-Ecosystem/gFTL/blob/dc93a5fc2fe2b487590580d9f0a17d77ca3fe5c1/include/v1/templates/set_impl.inc#L312 The type being transferred to an integer array may look like: ``` TYPE :: localwrapper TYPE(T), POINTER :: item END TYPE localwrapper ``` Which in flang case ends-up transferring a descriptor to an integer array, the code in gFTL later compare the integer arrays. This logic is used when building set data structures in gFTL.
2024-02-16 08:51:03 +01:00
static unsigned getLenParamFieldId(mlir::Type ty) {
return getTypeDescFieldId(ty) + 1;
}
[flang] Carry dynamic type in fir.rebox code generation Load the pointer of the dynamic type descriptor from the original box and update the destination descriptor with this pointer. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D136618
2022-10-24 20:42:31 +02:00
[mlir][LLVM] Add operand bundle support (#108933) This PR adds LLVM [operand bundle](https://llvm.org/docs/LangRef.html#operand-bundles) support to MLIR LLVM dialect. It affects these 3 operations related to making function calls: `llvm.call`, `llvm.invoke`, and `llvm.call_intrinsic`. This PR adds two new parameters to each of the 3 operations. The first parameter is a variadic operand `op_bundle_operands` that contains the SSA values for operand bundles. The second parameter is a property `op_bundle_tags` which holds an array of strings that represent the tags of each operand bundle.
2024-09-26 13:59:37 +08:00
static llvm::SmallVector<mlir::NamedAttribute>
addLLVMOpBundleAttrs(mlir::ConversionPatternRewriter &rewriter,
llvm::ArrayRef<mlir::NamedAttribute> attrs,
int32_t numCallOperands) {
llvm::SmallVector<mlir::NamedAttribute> newAttrs;
newAttrs.reserve(attrs.size() + 2);
for (mlir::NamedAttribute attr : attrs) {
if (attr.getName() != "operandSegmentSizes")
newAttrs.push_back(attr);
}
newAttrs.push_back(rewriter.getNamedAttr(
"operandSegmentSizes",
rewriter.getDenseI32ArrayAttr({numCallOperands, 0})));
newAttrs.push_back(rewriter.getNamedAttr("op_bundle_sizes",
rewriter.getDenseI32ArrayAttr({})));
return newAttrs;
}
[flang][NFC] Fix some formatting Fix some mismatch in format used in the file and reduce the diff with fir-dev to be able to finish the upstreaming on this file. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: PeteSteinfeld, kiranchandramohan Differential Revision: https://reviews.llvm.org/D127849
2022-06-15 16:48:46 +02:00
namespace {
/// Lower `fir.address_of` operation to `llvm.address_of` operation.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct AddrOfOpConversion : public fir::FIROpConversion<fir::AddrOfOp> {
[fir] Add base of the FIR to LLVM IR pass This patch adds the base of the FIR to LLVM IR Dialect conversion pass. It currently can convert the following operations: - fir.global - fir.has_value - fir.address_of - fir.undefined This patch is part of the upstreaming effort from fir-dev branch. It does not cover all FIR operations in order to have small patches. Several patches will follow to convert other operations. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D112845
2021-10-29 23:20:50 +02:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[fir] Add base of the FIR to LLVM IR pass This patch adds the base of the FIR to LLVM IR Dialect conversion pass. It currently can convert the following operations: - fir.global - fir.has_value - fir.address_of - fir.undefined This patch is part of the upstreaming effort from fir-dev branch. It does not cover all FIR operations in order to have small patches. Several patches will follow to convert other operations. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D112845
2021-10-29 23:20:50 +02:00
matchAndRewrite(fir::AddrOfOp addr, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
auto ty = convertType(addr.getType());
rewriter.replaceOpWithNewOp<mlir::LLVM::AddressOfOp>(
[flang][mlir][NFC] Replace uses of raw accessors with prefixed accessors `kEmitAccessorPrefix_Raw ` is being removed, and so updating the accessors to `kEmitAccessorPrefix_Prefixed`. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D119812
2022-02-15 20:35:46 +05:30
addr, ty, addr.getSymbol().getRootReference().getValue());
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[fir] Add base of the FIR to LLVM IR pass This patch adds the base of the FIR to LLVM IR Dialect conversion pass. It currently can convert the following operations: - fir.global - fir.has_value - fir.address_of - fir.undefined This patch is part of the upstreaming effort from fir-dev branch. It does not cover all FIR operations in order to have small patches. Several patches will follow to convert other operations. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D112845
2021-10-29 23:20:50 +02:00
}
};
[fir] Add !fir.alloca conversion Convert !fir.alloca into !llvm.alloca. This also contains a fix for verifyInType in FIROps.cpp, to make sure we can handle a !fir.ptr<!fir.array<?xN>>. Differential Revision: https://reviews.llvm.org/D113563 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-08 10:59:48 +00:00
} // namespace
/// Lookup the function to compute the memory size of this parametric derived
/// type. The size of the object may depend on the LEN type parameters of the
/// derived type.
static mlir::LLVM::LLVMFuncOp
getDependentTypeMemSizeFn(fir::RecordType recTy, fir::AllocaOp op,
mlir::ConversionPatternRewriter &rewriter) {
auto module = op->getParentOfType<mlir::ModuleOp>();
std::string name = recTy.getName().str() + "P.mem.size";
[flang][NFC] Fix some formatting Fix some mismatch in format used in the file and reduce the diff with fir-dev to be able to finish the upstreaming on this file. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: PeteSteinfeld, kiranchandramohan Differential Revision: https://reviews.llvm.org/D127849
2022-06-15 16:48:46 +02:00
if (auto memSizeFunc = module.lookupSymbol<mlir::LLVM::LLVMFuncOp>(name))
return memSizeFunc;
TODO(op.getLoc(), "did not find allocation function");
[fir] Add !fir.alloca conversion Convert !fir.alloca into !llvm.alloca. This also contains a fix for verifyInType in FIROps.cpp, to make sure we can handle a !fir.ptr<!fir.array<?xN>>. Differential Revision: https://reviews.llvm.org/D113563 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-08 10:59:48 +00:00
}
[flang] Fix AllocaOp/AllocMemOp type conversion For arrays without a constant interior or arrays of character with dynamic length arrays, the data types are converted to a pointer to the element type, so the scale size of the constant extents needs to be counted. The previous AllocaOp conversion does not consider the arrays of character with dynamic length arrays, and the previous AllocMemOp conversion does not consider arrays without a constant interior. This fixes them and refactors the code so that it can be shared. Also add the test cases. Reviewed By: Jean Perier Differential Revision: https://reviews.llvm.org/D124766
2022-05-06 22:10:13 +08:00
// Compute the alloc scale size (constant factors encoded in the array type).
// We do this for arrays without a constant interior or arrays of character with
// dynamic length arrays, since those are the only ones that get decayed to a
// pointer to the element type.
template <typename OP>
static mlir::Value
genAllocationScaleSize(OP op, mlir::Type ity,
mlir::ConversionPatternRewriter &rewriter) {
mlir::Location loc = op.getLoc();
mlir::Type dataTy = op.getInType();
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
auto seqTy = mlir::dyn_cast<fir::SequenceType>(dataTy);
[flang]Fix incorrect array type transformation When an array is defined with "unknown" size, such as fir.array<2x?x5xi32>, it should be converted to llvm.array<10 x i32>. The code so far has been converting it to llvm.ptr<i32>. Using a different function to check the if there starting are constant dimensions, rather than if ALL dimensions are constant, it now produces the correct array form. Some tests has been updated, so they are now checking the new behaviour rather than the old behaviour - so there's no need to add further tests for this particular scenario. This was originally found when compiling Spec 17 code, where an assert in a GepOP was hit. That is bug #56141, which this change fixes. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D129196
2022-07-06 13:38:47 +01:00
fir::SequenceType::Extent constSize = 1;
if (seqTy) {
int constRows = seqTy.getConstantRows();
const fir::SequenceType::ShapeRef &shape = seqTy.getShape();
if (constRows != static_cast<int>(shape.size())) {
for (auto extent : shape) {
if (constRows-- > 0)
continue;
if (extent != fir::SequenceType::getUnknownExtent())
constSize *= extent;
}
[flang] Fix AllocaOp/AllocMemOp type conversion For arrays without a constant interior or arrays of character with dynamic length arrays, the data types are converted to a pointer to the element type, so the scale size of the constant extents needs to be counted. The previous AllocaOp conversion does not consider the arrays of character with dynamic length arrays, and the previous AllocMemOp conversion does not consider arrays without a constant interior. This fixes them and refactors the code so that it can be shared. Also add the test cases. Reviewed By: Jean Perier Differential Revision: https://reviews.llvm.org/D124766
2022-05-06 22:10:13 +08:00
}
}
[flang]Fix incorrect array type transformation When an array is defined with "unknown" size, such as fir.array<2x?x5xi32>, it should be converted to llvm.array<10 x i32>. The code so far has been converting it to llvm.ptr<i32>. Using a different function to check the if there starting are constant dimensions, rather than if ALL dimensions are constant, it now produces the correct array form. Some tests has been updated, so they are now checking the new behaviour rather than the old behaviour - so there's no need to add further tests for this particular scenario. This was originally found when compiling Spec 17 code, where an assert in a GepOP was hit. That is bug #56141, which this change fixes. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D129196
2022-07-06 13:38:47 +01:00
if (constSize != 1) {
mlir::Value constVal{
genConstantIndex(loc, ity, rewriter, constSize).getResult()};
return constVal;
}
[flang] Fix AllocaOp/AllocMemOp type conversion For arrays without a constant interior or arrays of character with dynamic length arrays, the data types are converted to a pointer to the element type, so the scale size of the constant extents needs to be counted. The previous AllocaOp conversion does not consider the arrays of character with dynamic length arrays, and the previous AllocMemOp conversion does not consider arrays without a constant interior. This fixes them and refactors the code so that it can be shared. Also add the test cases. Reviewed By: Jean Perier Differential Revision: https://reviews.llvm.org/D124766
2022-05-06 22:10:13 +08:00
return nullptr;
}
[reland][flang] Initial debug info support for local variables (#92304) This is same as #90905 with an added fix. The issue was that we generated variable info even when user asked for line-tables-only. This caused llvm dwarf generation code to fail an assertion as it expected an empty variable list. Fixed by not generating debug info for variables when user wants only line table. I also updated a test check for this case.
2024-05-16 09:10:59 +01:00
namespace {
struct DeclareOpConversion : public fir::FIROpConversion<fir::cg::XDeclareOp> {
public:
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[reland][flang] Initial debug info support for local variables (#92304) This is same as #90905 with an added fix. The issue was that we generated variable info even when user asked for line-tables-only. This caused llvm dwarf generation code to fail an assertion as it expected an empty variable list. Fixed by not generating debug info for variables when user wants only line table. I also updated a test check for this case.
2024-05-16 09:10:59 +01:00
matchAndRewrite(fir::cg::XDeclareOp declareOp, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
auto memRef = adaptor.getOperands()[0];
if (auto fusedLoc = mlir::dyn_cast<mlir::FusedLoc>(declareOp.getLoc())) {
if (auto varAttr =
mlir::dyn_cast_or_null<mlir::LLVM::DILocalVariableAttr>(
fusedLoc.getMetadata())) {
rewriter.create<mlir::LLVM::DbgDeclareOp>(memRef.getLoc(), memRef,
varAttr, nullptr);
}
}
rewriter.replaceOp(declareOp, memRef);
return mlir::success();
}
};
} // namespace
[fir] Add !fir.alloca conversion Convert !fir.alloca into !llvm.alloca. This also contains a fix for verifyInType in FIROps.cpp, to make sure we can handle a !fir.ptr<!fir.array<?xN>>. Differential Revision: https://reviews.llvm.org/D113563 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-08 10:59:48 +00:00
namespace {
/// convert to LLVM IR dialect `alloca`
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct AllocaOpConversion : public fir::FIROpConversion<fir::AllocaOp> {
[fir] Add !fir.alloca conversion Convert !fir.alloca into !llvm.alloca. This also contains a fix for verifyInType in FIROps.cpp, to make sure we can handle a !fir.ptr<!fir.array<?xN>>. Differential Revision: https://reviews.llvm.org/D113563 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-08 10:59:48 +00:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[fir] Add !fir.alloca conversion Convert !fir.alloca into !llvm.alloca. This also contains a fix for verifyInType in FIROps.cpp, to make sure we can handle a !fir.ptr<!fir.array<?xN>>. Differential Revision: https://reviews.llvm.org/D113563 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-08 10:59:48 +00:00
matchAndRewrite(fir::AllocaOp alloc, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
mlir::ValueRange operands = adaptor.getOperands();
auto loc = alloc.getLoc();
mlir::Type ity = lowerTy().indexType();
unsigned i = 0;
mlir::Value size = genConstantIndex(loc, ity, rewriter, 1).getResult();
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::Type firObjType = fir::unwrapRefType(alloc.getType());
mlir::Type llvmObjectType = convertObjectType(firObjType);
[fir] Add !fir.alloca conversion Convert !fir.alloca into !llvm.alloca. This also contains a fix for verifyInType in FIROps.cpp, to make sure we can handle a !fir.ptr<!fir.array<?xN>>. Differential Revision: https://reviews.llvm.org/D113563 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-08 10:59:48 +00:00
if (alloc.hasLenParams()) {
unsigned end = alloc.numLenParams();
llvm::SmallVector<mlir::Value> lenParams;
for (; i < end; ++i)
lenParams.push_back(operands[i]);
mlir::Type scalarType = fir::unwrapSequenceType(alloc.getInType());
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (auto chrTy = mlir::dyn_cast<fir::CharacterType>(scalarType)) {
[fir] Add !fir.alloca conversion Convert !fir.alloca into !llvm.alloca. This also contains a fix for verifyInType in FIROps.cpp, to make sure we can handle a !fir.ptr<!fir.array<?xN>>. Differential Revision: https://reviews.llvm.org/D113563 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-08 10:59:48 +00:00
fir::CharacterType rawCharTy = fir::CharacterType::getUnknownLen(
chrTy.getContext(), chrTy.getFKind());
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
llvmObjectType = convertType(rawCharTy);
[fir] Add !fir.alloca conversion Convert !fir.alloca into !llvm.alloca. This also contains a fix for verifyInType in FIROps.cpp, to make sure we can handle a !fir.ptr<!fir.array<?xN>>. Differential Revision: https://reviews.llvm.org/D113563 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-08 10:59:48 +00:00
assert(end == 1);
[Flang] Hoisting constant-sized allocas at flang codegen. (#95310) This change modifies the `AllocaOpConversion` in flang codegen to insert constant-sized LLVM allocas at the entry block of `LLVMFuncOp` or OpenACC/OpenMP Op, rather than in-place at the `fir.alloca`. This effectively hoists constant-sized FIR allocas to the proper block. When compiling the example subroutine below with `flang-new`, we get a llvm.stacksave/stackrestore pair around a constant-sized `fir.alloca i32`. ``` subroutine test(n) block integer :: n print *, n end block end subroutine test ``` Without the proposed change, downstream LLVM compilation cannot hoist this constant-sized alloca out of the stacksave/stackrestore region which may lead to missed downstream optimizations: ``` *** IR Dump After Safe Stack instrumentation pass (safe-stack) *** define void @test_(ptr %0) !dbg !3 { %2 = call ptr @llvm.stacksave.p0(), !dbg !7 %3 = alloca i32, i64 1, align 4, !dbg !8 %4 = call ptr @_FortranAioBeginExternalListOutput(i32 6, ptr @_QQclX62c91d05f046c7a656e7978eb13f2821, i32 4), !dbg !9 %5 = load i32, ptr %3, align 4, !dbg !10, !tbaa !11 %6 = call i1 @_FortranAioOutputInteger32(ptr %4, i32 %5), !dbg !10 %7 = call i32 @_FortranAioEndIoStatement(ptr %4), !dbg !9 call void @llvm.stackrestore.p0(ptr %2), !dbg !15 ret void, !dbg !16 } ``` With this change, the `llvm.alloca` is already hoisted out of the stacksave/stackrestore region during flang codegen: ``` // -----// IR Dump After FIRToLLVMLowering (fir-to-llvm-ir) //----- // llvm.func @test_(%arg0: !llvm.ptr {fir.bindc_name = "n"}) attributes {fir.internal_name = "_QPtest"} { %0 = llvm.mlir.constant(4 : i32) : i32 %1 = llvm.mlir.constant(1 : i64) : i64 %2 = llvm.alloca %1 x i32 {bindc_name = "n"} : (i64) -> !llvm.ptr %3 = llvm.mlir.constant(6 : i32) : i32 %4 = llvm.mlir.undef : i1 %5 = llvm.call @llvm.stacksave.p0() {fastmathFlags = #llvm.fastmath<contract>} : () -> !llvm.ptr %6 = llvm.mlir.addressof @_QQclX62c91d05f046c7a656e7978eb13f2821 : !llvm.ptr %7 = llvm.call @_FortranAioBeginExternalListOutput(%3, %6, %0) {fastmathFlags = #llvm.fastmath<contract>} : (i32, !llvm.ptr, i32) -> !llvm.ptr %8 = llvm.load %2 {tbaa = [#tbaa_tag]} : !llvm.ptr -> i32 %9 = llvm.call @_FortranAioOutputInteger32(%7, %8) {fastmathFlags = #llvm.fastmath<contract>} : (!llvm.ptr, i32) -> i1 %10 = llvm.call @_FortranAioEndIoStatement(%7) {fastmathFlags = #llvm.fastmath<contract>} : (!llvm.ptr) -> i32 llvm.call @llvm.stackrestore.p0(%5) {fastmathFlags = #llvm.fastmath<contract>} : (!llvm.ptr) -> () llvm.return } ``` --------- Co-authored-by: Vijay Kandiah <vkandiah@sky6.pgi.net>
2024-06-14 11:36:05 -05:00
size = integerCast(loc, rewriter, ity, lenParams[0], /*fold=*/true);
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
} else if (auto recTy = mlir::dyn_cast<fir::RecordType>(scalarType)) {
[fir] Add !fir.alloca conversion Convert !fir.alloca into !llvm.alloca. This also contains a fix for verifyInType in FIROps.cpp, to make sure we can handle a !fir.ptr<!fir.array<?xN>>. Differential Revision: https://reviews.llvm.org/D113563 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-08 10:59:48 +00:00
mlir::LLVM::LLVMFuncOp memSizeFn =
getDependentTypeMemSizeFn(recTy, alloc, rewriter);
if (!memSizeFn)
emitError(loc, "did not find allocation function");
mlir::NamedAttribute attr = rewriter.getNamedAttr(
"callee", mlir::SymbolRefAttr::get(memSizeFn));
auto call = rewriter.create<mlir::LLVM::CallOp>(
[mlir][LLVM] Add operand bundle support (#108933) This PR adds LLVM [operand bundle](https://llvm.org/docs/LangRef.html#operand-bundles) support to MLIR LLVM dialect. It affects these 3 operations related to making function calls: `llvm.call`, `llvm.invoke`, and `llvm.call_intrinsic`. This PR adds two new parameters to each of the 3 operations. The first parameter is a variadic operand `op_bundle_operands` that contains the SSA values for operand bundles. The second parameter is a property `op_bundle_tags` which holds an array of strings that represent the tags of each operand bundle.
2024-09-26 13:59:37 +08:00
loc, ity, lenParams,
addLLVMOpBundleAttrs(rewriter, {attr}, lenParams.size()));
[fir] Fix build
2022-08-11 01:10:27 -04:00
size = call.getResult();
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
llvmObjectType = ::getI8Type(alloc.getContext());
[fir] Add !fir.alloca conversion Convert !fir.alloca into !llvm.alloca. This also contains a fix for verifyInType in FIROps.cpp, to make sure we can handle a !fir.ptr<!fir.array<?xN>>. Differential Revision: https://reviews.llvm.org/D113563 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-08 10:59:48 +00:00
} else {
return emitError(loc, "unexpected type ")
<< scalarType << " with type parameters";
}
}
[flang] Fix AllocaOp/AllocMemOp type conversion For arrays without a constant interior or arrays of character with dynamic length arrays, the data types are converted to a pointer to the element type, so the scale size of the constant extents needs to be counted. The previous AllocaOp conversion does not consider the arrays of character with dynamic length arrays, and the previous AllocMemOp conversion does not consider arrays without a constant interior. This fixes them and refactors the code so that it can be shared. Also add the test cases. Reviewed By: Jean Perier Differential Revision: https://reviews.llvm.org/D124766
2022-05-06 22:10:13 +08:00
if (auto scaleSize = genAllocationScaleSize(alloc, ity, rewriter))
[Flang] Hoisting constant-sized allocas at flang codegen. (#95310) This change modifies the `AllocaOpConversion` in flang codegen to insert constant-sized LLVM allocas at the entry block of `LLVMFuncOp` or OpenACC/OpenMP Op, rather than in-place at the `fir.alloca`. This effectively hoists constant-sized FIR allocas to the proper block. When compiling the example subroutine below with `flang-new`, we get a llvm.stacksave/stackrestore pair around a constant-sized `fir.alloca i32`. ``` subroutine test(n) block integer :: n print *, n end block end subroutine test ``` Without the proposed change, downstream LLVM compilation cannot hoist this constant-sized alloca out of the stacksave/stackrestore region which may lead to missed downstream optimizations: ``` *** IR Dump After Safe Stack instrumentation pass (safe-stack) *** define void @test_(ptr %0) !dbg !3 { %2 = call ptr @llvm.stacksave.p0(), !dbg !7 %3 = alloca i32, i64 1, align 4, !dbg !8 %4 = call ptr @_FortranAioBeginExternalListOutput(i32 6, ptr @_QQclX62c91d05f046c7a656e7978eb13f2821, i32 4), !dbg !9 %5 = load i32, ptr %3, align 4, !dbg !10, !tbaa !11 %6 = call i1 @_FortranAioOutputInteger32(ptr %4, i32 %5), !dbg !10 %7 = call i32 @_FortranAioEndIoStatement(ptr %4), !dbg !9 call void @llvm.stackrestore.p0(ptr %2), !dbg !15 ret void, !dbg !16 } ``` With this change, the `llvm.alloca` is already hoisted out of the stacksave/stackrestore region during flang codegen: ``` // -----// IR Dump After FIRToLLVMLowering (fir-to-llvm-ir) //----- // llvm.func @test_(%arg0: !llvm.ptr {fir.bindc_name = "n"}) attributes {fir.internal_name = "_QPtest"} { %0 = llvm.mlir.constant(4 : i32) : i32 %1 = llvm.mlir.constant(1 : i64) : i64 %2 = llvm.alloca %1 x i32 {bindc_name = "n"} : (i64) -> !llvm.ptr %3 = llvm.mlir.constant(6 : i32) : i32 %4 = llvm.mlir.undef : i1 %5 = llvm.call @llvm.stacksave.p0() {fastmathFlags = #llvm.fastmath<contract>} : () -> !llvm.ptr %6 = llvm.mlir.addressof @_QQclX62c91d05f046c7a656e7978eb13f2821 : !llvm.ptr %7 = llvm.call @_FortranAioBeginExternalListOutput(%3, %6, %0) {fastmathFlags = #llvm.fastmath<contract>} : (i32, !llvm.ptr, i32) -> !llvm.ptr %8 = llvm.load %2 {tbaa = [#tbaa_tag]} : !llvm.ptr -> i32 %9 = llvm.call @_FortranAioOutputInteger32(%7, %8) {fastmathFlags = #llvm.fastmath<contract>} : (!llvm.ptr, i32) -> i1 %10 = llvm.call @_FortranAioEndIoStatement(%7) {fastmathFlags = #llvm.fastmath<contract>} : (!llvm.ptr) -> i32 llvm.call @llvm.stackrestore.p0(%5) {fastmathFlags = #llvm.fastmath<contract>} : (!llvm.ptr) -> () llvm.return } ``` --------- Co-authored-by: Vijay Kandiah <vkandiah@sky6.pgi.net>
2024-06-14 11:36:05 -05:00
size =
rewriter.createOrFold<mlir::LLVM::MulOp>(loc, ity, size, scaleSize);
[fir] Add !fir.alloca conversion Convert !fir.alloca into !llvm.alloca. This also contains a fix for verifyInType in FIROps.cpp, to make sure we can handle a !fir.ptr<!fir.array<?xN>>. Differential Revision: https://reviews.llvm.org/D113563 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-08 10:59:48 +00:00
if (alloc.hasShapeOperands()) {
unsigned end = operands.size();
for (; i < end; ++i)
[Flang] Hoisting constant-sized allocas at flang codegen. (#95310) This change modifies the `AllocaOpConversion` in flang codegen to insert constant-sized LLVM allocas at the entry block of `LLVMFuncOp` or OpenACC/OpenMP Op, rather than in-place at the `fir.alloca`. This effectively hoists constant-sized FIR allocas to the proper block. When compiling the example subroutine below with `flang-new`, we get a llvm.stacksave/stackrestore pair around a constant-sized `fir.alloca i32`. ``` subroutine test(n) block integer :: n print *, n end block end subroutine test ``` Without the proposed change, downstream LLVM compilation cannot hoist this constant-sized alloca out of the stacksave/stackrestore region which may lead to missed downstream optimizations: ``` *** IR Dump After Safe Stack instrumentation pass (safe-stack) *** define void @test_(ptr %0) !dbg !3 { %2 = call ptr @llvm.stacksave.p0(), !dbg !7 %3 = alloca i32, i64 1, align 4, !dbg !8 %4 = call ptr @_FortranAioBeginExternalListOutput(i32 6, ptr @_QQclX62c91d05f046c7a656e7978eb13f2821, i32 4), !dbg !9 %5 = load i32, ptr %3, align 4, !dbg !10, !tbaa !11 %6 = call i1 @_FortranAioOutputInteger32(ptr %4, i32 %5), !dbg !10 %7 = call i32 @_FortranAioEndIoStatement(ptr %4), !dbg !9 call void @llvm.stackrestore.p0(ptr %2), !dbg !15 ret void, !dbg !16 } ``` With this change, the `llvm.alloca` is already hoisted out of the stacksave/stackrestore region during flang codegen: ``` // -----// IR Dump After FIRToLLVMLowering (fir-to-llvm-ir) //----- // llvm.func @test_(%arg0: !llvm.ptr {fir.bindc_name = "n"}) attributes {fir.internal_name = "_QPtest"} { %0 = llvm.mlir.constant(4 : i32) : i32 %1 = llvm.mlir.constant(1 : i64) : i64 %2 = llvm.alloca %1 x i32 {bindc_name = "n"} : (i64) -> !llvm.ptr %3 = llvm.mlir.constant(6 : i32) : i32 %4 = llvm.mlir.undef : i1 %5 = llvm.call @llvm.stacksave.p0() {fastmathFlags = #llvm.fastmath<contract>} : () -> !llvm.ptr %6 = llvm.mlir.addressof @_QQclX62c91d05f046c7a656e7978eb13f2821 : !llvm.ptr %7 = llvm.call @_FortranAioBeginExternalListOutput(%3, %6, %0) {fastmathFlags = #llvm.fastmath<contract>} : (i32, !llvm.ptr, i32) -> !llvm.ptr %8 = llvm.load %2 {tbaa = [#tbaa_tag]} : !llvm.ptr -> i32 %9 = llvm.call @_FortranAioOutputInteger32(%7, %8) {fastmathFlags = #llvm.fastmath<contract>} : (!llvm.ptr, i32) -> i1 %10 = llvm.call @_FortranAioEndIoStatement(%7) {fastmathFlags = #llvm.fastmath<contract>} : (!llvm.ptr) -> i32 llvm.call @llvm.stackrestore.p0(%5) {fastmathFlags = #llvm.fastmath<contract>} : (!llvm.ptr) -> () llvm.return } ``` --------- Co-authored-by: Vijay Kandiah <vkandiah@sky6.pgi.net>
2024-06-14 11:36:05 -05:00
size = rewriter.createOrFold<mlir::LLVM::MulOp>(
loc, ity, size,
integerCast(loc, rewriter, ity, operands[i], /*fold=*/true));
[fir] Add !fir.alloca conversion Convert !fir.alloca into !llvm.alloca. This also contains a fix for verifyInType in FIROps.cpp, to make sure we can handle a !fir.ptr<!fir.array<?xN>>. Differential Revision: https://reviews.llvm.org/D113563 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-08 10:59:48 +00:00
}
[Flang][MLIR] Add basic initial support for alloca and program address space handling in FIR->LLVMIR codegen (#77518) This is a slightly more slimmed down and up-to-date version of the older PR from here: https://reviews.llvm.org/D144203, written by @jsjodin, which has already under gone some review. This PR places allocas in the alloca address space specified by the provided data layout (default is 0 for all address spaces, unless explicitly specified by the layout), and then will cast these alloca's to the program address space if this address space is different from the allocation address space. For most architectures data layouts, this will be a no-op, as they have a flat address space. But in the case of AMDGPU it will result in allocas being placed in the correct address space (5, private), and then casted into the correct program address space (0, generic). This results in correct (partially, a follow up PR will be forthcoming soon) generation of allocations inside of device code. This PR is in addition to the work by @skatrak in this PR: https://github.com/llvm/llvm-project/pull/69599 and adds seperate and neccesary functionality of casting alloca's from their address space to the program address space, both are independent PRs, although there is some minor overlap e.g. this PR incorporates some of the useful helper functions from 69599, so whichever lands first will need a minor rebase. Co-author: jsjodin
2024-01-17 17:37:16 +01:00
unsigned allocaAs = getAllocaAddressSpace(rewriter);
unsigned programAs = getProgramAddressSpace(rewriter);
[Flang] Hoisting constant-sized allocas at flang codegen. (#95310) This change modifies the `AllocaOpConversion` in flang codegen to insert constant-sized LLVM allocas at the entry block of `LLVMFuncOp` or OpenACC/OpenMP Op, rather than in-place at the `fir.alloca`. This effectively hoists constant-sized FIR allocas to the proper block. When compiling the example subroutine below with `flang-new`, we get a llvm.stacksave/stackrestore pair around a constant-sized `fir.alloca i32`. ``` subroutine test(n) block integer :: n print *, n end block end subroutine test ``` Without the proposed change, downstream LLVM compilation cannot hoist this constant-sized alloca out of the stacksave/stackrestore region which may lead to missed downstream optimizations: ``` *** IR Dump After Safe Stack instrumentation pass (safe-stack) *** define void @test_(ptr %0) !dbg !3 { %2 = call ptr @llvm.stacksave.p0(), !dbg !7 %3 = alloca i32, i64 1, align 4, !dbg !8 %4 = call ptr @_FortranAioBeginExternalListOutput(i32 6, ptr @_QQclX62c91d05f046c7a656e7978eb13f2821, i32 4), !dbg !9 %5 = load i32, ptr %3, align 4, !dbg !10, !tbaa !11 %6 = call i1 @_FortranAioOutputInteger32(ptr %4, i32 %5), !dbg !10 %7 = call i32 @_FortranAioEndIoStatement(ptr %4), !dbg !9 call void @llvm.stackrestore.p0(ptr %2), !dbg !15 ret void, !dbg !16 } ``` With this change, the `llvm.alloca` is already hoisted out of the stacksave/stackrestore region during flang codegen: ``` // -----// IR Dump After FIRToLLVMLowering (fir-to-llvm-ir) //----- // llvm.func @test_(%arg0: !llvm.ptr {fir.bindc_name = "n"}) attributes {fir.internal_name = "_QPtest"} { %0 = llvm.mlir.constant(4 : i32) : i32 %1 = llvm.mlir.constant(1 : i64) : i64 %2 = llvm.alloca %1 x i32 {bindc_name = "n"} : (i64) -> !llvm.ptr %3 = llvm.mlir.constant(6 : i32) : i32 %4 = llvm.mlir.undef : i1 %5 = llvm.call @llvm.stacksave.p0() {fastmathFlags = #llvm.fastmath<contract>} : () -> !llvm.ptr %6 = llvm.mlir.addressof @_QQclX62c91d05f046c7a656e7978eb13f2821 : !llvm.ptr %7 = llvm.call @_FortranAioBeginExternalListOutput(%3, %6, %0) {fastmathFlags = #llvm.fastmath<contract>} : (i32, !llvm.ptr, i32) -> !llvm.ptr %8 = llvm.load %2 {tbaa = [#tbaa_tag]} : !llvm.ptr -> i32 %9 = llvm.call @_FortranAioOutputInteger32(%7, %8) {fastmathFlags = #llvm.fastmath<contract>} : (!llvm.ptr, i32) -> i1 %10 = llvm.call @_FortranAioEndIoStatement(%7) {fastmathFlags = #llvm.fastmath<contract>} : (!llvm.ptr) -> i32 llvm.call @llvm.stackrestore.p0(%5) {fastmathFlags = #llvm.fastmath<contract>} : (!llvm.ptr) -> () llvm.return } ``` --------- Co-authored-by: Vijay Kandiah <vkandiah@sky6.pgi.net>
2024-06-14 11:36:05 -05:00
if (mlir::isa<mlir::LLVM::ConstantOp>(size.getDefiningOp())) {
// Set the Block in which the llvm alloca should be inserted.
mlir::Operation *parentOp = rewriter.getInsertionBlock()->getParentOp();
mlir::Region *parentRegion = rewriter.getInsertionBlock()->getParent();
mlir::Block *insertBlock =
getBlockForAllocaInsert(parentOp, parentRegion);
[flang][CodeGen] fix bug hoisting allocas using a shared constant arg (#116251) When hoisting the allocas with a constant integer size, the constant integer was moved to where the alloca is hoisted to unconditionally. By CodeGen there have been various iterations of mlir canonicalization and dead code elimination. This can cause lots of unrelated bits of code to share the same constant values. If for some reason the alloca couldn't be hoisted all of the way to the entry block of the function, moving the constant might result in it no-longer dominating some of the remaining uses. In theory, there should be dominance analysis to ensure the location of the constant does dominate all uses of it. But those constants are effectively free anyway (they aren't even separate instructions in LLVM IR), so it is less expensive just to leave the old one where it was and insert a new one we know for sure is immediately before the alloca.
2024-11-15 10:31:20 +00:00
// The old size might have had multiple users, some at a broader scope
// than we can safely outline the alloca to. As it is only an
// llvm.constant operation, it is faster to clone it than to calculate the
// dominance to see if it really should be moved.
mlir::Operation *clonedSize = rewriter.clone(*size.getDefiningOp());
size = clonedSize->getResult(0);
clonedSize->moveBefore(&insertBlock->front());
[Flang] Hoisting constant-sized allocas at flang codegen. (#95310) This change modifies the `AllocaOpConversion` in flang codegen to insert constant-sized LLVM allocas at the entry block of `LLVMFuncOp` or OpenACC/OpenMP Op, rather than in-place at the `fir.alloca`. This effectively hoists constant-sized FIR allocas to the proper block. When compiling the example subroutine below with `flang-new`, we get a llvm.stacksave/stackrestore pair around a constant-sized `fir.alloca i32`. ``` subroutine test(n) block integer :: n print *, n end block end subroutine test ``` Without the proposed change, downstream LLVM compilation cannot hoist this constant-sized alloca out of the stacksave/stackrestore region which may lead to missed downstream optimizations: ``` *** IR Dump After Safe Stack instrumentation pass (safe-stack) *** define void @test_(ptr %0) !dbg !3 { %2 = call ptr @llvm.stacksave.p0(), !dbg !7 %3 = alloca i32, i64 1, align 4, !dbg !8 %4 = call ptr @_FortranAioBeginExternalListOutput(i32 6, ptr @_QQclX62c91d05f046c7a656e7978eb13f2821, i32 4), !dbg !9 %5 = load i32, ptr %3, align 4, !dbg !10, !tbaa !11 %6 = call i1 @_FortranAioOutputInteger32(ptr %4, i32 %5), !dbg !10 %7 = call i32 @_FortranAioEndIoStatement(ptr %4), !dbg !9 call void @llvm.stackrestore.p0(ptr %2), !dbg !15 ret void, !dbg !16 } ``` With this change, the `llvm.alloca` is already hoisted out of the stacksave/stackrestore region during flang codegen: ``` // -----// IR Dump After FIRToLLVMLowering (fir-to-llvm-ir) //----- // llvm.func @test_(%arg0: !llvm.ptr {fir.bindc_name = "n"}) attributes {fir.internal_name = "_QPtest"} { %0 = llvm.mlir.constant(4 : i32) : i32 %1 = llvm.mlir.constant(1 : i64) : i64 %2 = llvm.alloca %1 x i32 {bindc_name = "n"} : (i64) -> !llvm.ptr %3 = llvm.mlir.constant(6 : i32) : i32 %4 = llvm.mlir.undef : i1 %5 = llvm.call @llvm.stacksave.p0() {fastmathFlags = #llvm.fastmath<contract>} : () -> !llvm.ptr %6 = llvm.mlir.addressof @_QQclX62c91d05f046c7a656e7978eb13f2821 : !llvm.ptr %7 = llvm.call @_FortranAioBeginExternalListOutput(%3, %6, %0) {fastmathFlags = #llvm.fastmath<contract>} : (i32, !llvm.ptr, i32) -> !llvm.ptr %8 = llvm.load %2 {tbaa = [#tbaa_tag]} : !llvm.ptr -> i32 %9 = llvm.call @_FortranAioOutputInteger32(%7, %8) {fastmathFlags = #llvm.fastmath<contract>} : (!llvm.ptr, i32) -> i1 %10 = llvm.call @_FortranAioEndIoStatement(%7) {fastmathFlags = #llvm.fastmath<contract>} : (!llvm.ptr) -> i32 llvm.call @llvm.stackrestore.p0(%5) {fastmathFlags = #llvm.fastmath<contract>} : (!llvm.ptr) -> () llvm.return } ``` --------- Co-authored-by: Vijay Kandiah <vkandiah@sky6.pgi.net>
2024-06-14 11:36:05 -05:00
rewriter.setInsertionPointAfter(size.getDefiningOp());
}
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
// NOTE: we used to pass alloc->getAttrs() in the builder for non opaque
// pointers! Only propagate pinned and bindc_name to help debugging, but
// this should have no functional purpose (and passing the operand segment
// attribute like before is certainly bad).
auto llvmAlloc = rewriter.create<mlir::LLVM::AllocaOp>(
[Flang][MLIR] Add basic initial support for alloca and program address space handling in FIR->LLVMIR codegen (#77518) This is a slightly more slimmed down and up-to-date version of the older PR from here: https://reviews.llvm.org/D144203, written by @jsjodin, which has already under gone some review. This PR places allocas in the alloca address space specified by the provided data layout (default is 0 for all address spaces, unless explicitly specified by the layout), and then will cast these alloca's to the program address space if this address space is different from the allocation address space. For most architectures data layouts, this will be a no-op, as they have a flat address space. But in the case of AMDGPU it will result in allocas being placed in the correct address space (5, private), and then casted into the correct program address space (0, generic). This results in correct (partially, a follow up PR will be forthcoming soon) generation of allocations inside of device code. This PR is in addition to the work by @skatrak in this PR: https://github.com/llvm/llvm-project/pull/69599 and adds seperate and neccesary functionality of casting alloca's from their address space to the program address space, both are independent PRs, although there is some minor overlap e.g. this PR incorporates some of the useful helper functions from 69599, so whichever lands first will need a minor rebase. Co-author: jsjodin
2024-01-17 17:37:16 +01:00
loc, ::getLlvmPtrType(alloc.getContext(), allocaAs), llvmObjectType,
size);
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
if (alloc.getPinned())
llvmAlloc->setDiscardableAttr(alloc.getPinnedAttrName(),
alloc.getPinnedAttr());
if (alloc.getBindcName())
llvmAlloc->setDiscardableAttr(alloc.getBindcNameAttrName(),
alloc.getBindcNameAttr());
[Flang][MLIR] Add basic initial support for alloca and program address space handling in FIR->LLVMIR codegen (#77518) This is a slightly more slimmed down and up-to-date version of the older PR from here: https://reviews.llvm.org/D144203, written by @jsjodin, which has already under gone some review. This PR places allocas in the alloca address space specified by the provided data layout (default is 0 for all address spaces, unless explicitly specified by the layout), and then will cast these alloca's to the program address space if this address space is different from the allocation address space. For most architectures data layouts, this will be a no-op, as they have a flat address space. But in the case of AMDGPU it will result in allocas being placed in the correct address space (5, private), and then casted into the correct program address space (0, generic). This results in correct (partially, a follow up PR will be forthcoming soon) generation of allocations inside of device code. This PR is in addition to the work by @skatrak in this PR: https://github.com/llvm/llvm-project/pull/69599 and adds seperate and neccesary functionality of casting alloca's from their address space to the program address space, both are independent PRs, although there is some minor overlap e.g. this PR incorporates some of the useful helper functions from 69599, so whichever lands first will need a minor rebase. Co-author: jsjodin
2024-01-17 17:37:16 +01:00
if (allocaAs == programAs) {
rewriter.replaceOp(alloc, llvmAlloc);
} else {
// if our allocation address space, is not the same as the program address
// space, then we must emit a cast to the program address space before
// use. An example case would be on AMDGPU, where the allocation address
// space is the numeric value 5 (private), and the program address space
// is 0 (generic).
rewriter.replaceOpWithNewOp<mlir::LLVM::AddrSpaceCastOp>(
alloc, ::getLlvmPtrType(alloc.getContext(), programAs), llvmAlloc);
}
[flang][cuda] Lower match_all_sync functions to nvvm intrinsics (#127940)
2025-02-20 09:10:25 -08:00
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[fir] Add !fir.alloca conversion Convert !fir.alloca into !llvm.alloca. This also contains a fix for verifyInType in FIROps.cpp, to make sure we can handle a !fir.ptr<!fir.array<?xN>>. Differential Revision: https://reviews.llvm.org/D113563 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-08 10:59:48 +00:00
}
};
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
} // namespace
namespace {
[fir] Add fir.box_rank, fir.box_addr, fir.box_dims and fir.box_elesize conversion This patch adds conversion for basic box operations that extract information from the box. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113551 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-10 15:28:26 +01:00
/// Lower `fir.box_addr` to the sequence of operations to extract the first
/// element of the box.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct BoxAddrOpConversion : public fir::FIROpConversion<fir::BoxAddrOp> {
[fir] Add fir.box_rank, fir.box_addr, fir.box_dims and fir.box_elesize conversion This patch adds conversion for basic box operations that extract information from the box. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113551 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-10 15:28:26 +01:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[fir] Add fir.box_rank, fir.box_addr, fir.box_dims and fir.box_elesize conversion This patch adds conversion for basic box operations that extract information from the box. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113551 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-10 15:28:26 +01:00
matchAndRewrite(fir::BoxAddrOp boxaddr, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
mlir::Value a = adaptor.getOperands()[0];
auto loc = boxaddr.getLoc();
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (auto argty =
mlir::dyn_cast<fir::BaseBoxType>(boxaddr.getVal().getType())) {
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
TypePair boxTyPair = getBoxTypePair(argty);
[flang] Generate TBAA information. This is initial version of TBAA information generation for Flang generated IR. The desired behavior is that TBAA type descriptors are generated for FIR types during FIR to LLVM types conversion, and then TBAA access tags are attached to memory accessing operations when they are converted to LLVM IR dialect. In the initial version the type conversion is not producing TBAA type descriptors, and all memory accesses are just partitioned into two sets of box and non-box accesses, which can never alias. The TBAA generation is enabled by default at >O0 optimization levels. TBAA generation may also be enabled via `apply-tbaa` option of `fir-to-llvm-ir` conversion pass. `-mllvm -disable-tbaa` engineering option allows disabling TBAA generation to override Flang's default (e.g. when -O1 is used). SPEC CPU2006/437.leslie3d speeds up by more than 2x on Icelake. Reviewed By: jeanPerier, clementval Differential Revision: https://reviews.llvm.org/D141820
2023-01-17 09:08:43 -08:00
rewriter.replaceOp(boxaddr,
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
getBaseAddrFromBox(loc, boxTyPair, a, rewriter));
[fir] Add fir.box_rank, fir.box_addr, fir.box_dims and fir.box_elesize conversion This patch adds conversion for basic box operations that extract information from the box. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113551 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-10 15:28:26 +01:00
} else {
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
rewriter.replaceOpWithNewOp<mlir::LLVM::ExtractValueOp>(boxaddr, a, 0);
[fir] Add fir.box_rank, fir.box_addr, fir.box_dims and fir.box_elesize conversion This patch adds conversion for basic box operations that extract information from the box. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113551 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-10 15:28:26 +01:00
}
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[fir] Add fir.box_rank, fir.box_addr, fir.box_dims and fir.box_elesize conversion This patch adds conversion for basic box operations that extract information from the box. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113551 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-10 15:28:26 +01:00
}
};
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// Convert `!fir.boxchar_len` to `!llvm.extractvalue` for the 2nd part of the
/// boxchar.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct BoxCharLenOpConversion : public fir::FIROpConversion<fir::BoxCharLenOp> {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::BoxCharLenOp boxCharLen, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
mlir::Value boxChar = adaptor.getOperands()[0];
mlir::Location loc = boxChar.getLoc();
mlir::Type returnValTy = boxCharLen.getResult().getType();
constexpr int boxcharLenIdx = 1;
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
auto len = rewriter.create<mlir::LLVM::ExtractValueOp>(loc, boxChar,
boxcharLenIdx);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::Value lenAfterCast = integerCast(loc, rewriter, returnValTy, len);
rewriter.replaceOp(boxCharLen, lenAfterCast);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
};
[fir] Add fir.box_rank, fir.box_addr, fir.box_dims and fir.box_elesize conversion This patch adds conversion for basic box operations that extract information from the box. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113551 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-10 15:28:26 +01:00
/// Lower `fir.box_dims` to a sequence of operations to extract the requested
[flang] Generate TBAA information. This is initial version of TBAA information generation for Flang generated IR. The desired behavior is that TBAA type descriptors are generated for FIR types during FIR to LLVM types conversion, and then TBAA access tags are attached to memory accessing operations when they are converted to LLVM IR dialect. In the initial version the type conversion is not producing TBAA type descriptors, and all memory accesses are just partitioned into two sets of box and non-box accesses, which can never alias. The TBAA generation is enabled by default at >O0 optimization levels. TBAA generation may also be enabled via `apply-tbaa` option of `fir-to-llvm-ir` conversion pass. `-mllvm -disable-tbaa` engineering option allows disabling TBAA generation to override Flang's default (e.g. when -O1 is used). SPEC CPU2006/437.leslie3d speeds up by more than 2x on Icelake. Reviewed By: jeanPerier, clementval Differential Revision: https://reviews.llvm.org/D141820
2023-01-17 09:08:43 -08:00
/// dimension information from the boxed value.
[fir] Add fir.box_rank, fir.box_addr, fir.box_dims and fir.box_elesize conversion This patch adds conversion for basic box operations that extract information from the box. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113551 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-10 15:28:26 +01:00
/// Result in a triple set of GEPs and loads.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct BoxDimsOpConversion : public fir::FIROpConversion<fir::BoxDimsOp> {
[fir] Add fir.box_rank, fir.box_addr, fir.box_dims and fir.box_elesize conversion This patch adds conversion for basic box operations that extract information from the box. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113551 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-10 15:28:26 +01:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[fir] Add fir.box_rank, fir.box_addr, fir.box_dims and fir.box_elesize conversion This patch adds conversion for basic box operations that extract information from the box. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113551 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-10 15:28:26 +01:00
matchAndRewrite(fir::BoxDimsOp boxdims, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
llvm::SmallVector<mlir::Type, 3> resultTypes = {
[fir] Add fir.box_rank, fir.box_addr, fir.box_dims and fir.box_elesize conversion This patch adds conversion for basic box operations that extract information from the box. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113551 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-10 15:28:26 +01:00
convertType(boxdims.getResult(0).getType()),
convertType(boxdims.getResult(1).getType()),
convertType(boxdims.getResult(2).getType()),
};
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
TypePair boxTyPair = getBoxTypePair(boxdims.getVal().getType());
auto results = getDimsFromBox(boxdims.getLoc(), resultTypes, boxTyPair,
adaptor.getOperands()[0],
adaptor.getOperands()[1], rewriter);
[fir] Add fir.box_rank, fir.box_addr, fir.box_dims and fir.box_elesize conversion This patch adds conversion for basic box operations that extract information from the box. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113551 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-10 15:28:26 +01:00
rewriter.replaceOp(boxdims, results);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[fir] Add fir.box_rank, fir.box_addr, fir.box_dims and fir.box_elesize conversion This patch adds conversion for basic box operations that extract information from the box. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113551 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-10 15:28:26 +01:00
}
};
/// Lower `fir.box_elesize` to a sequence of operations ro extract the size of
/// an element in the boxed value.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct BoxEleSizeOpConversion : public fir::FIROpConversion<fir::BoxEleSizeOp> {
[fir] Add fir.box_rank, fir.box_addr, fir.box_dims and fir.box_elesize conversion This patch adds conversion for basic box operations that extract information from the box. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113551 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-10 15:28:26 +01:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[fir] Add fir.box_rank, fir.box_addr, fir.box_dims and fir.box_elesize conversion This patch adds conversion for basic box operations that extract information from the box. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113551 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-10 15:28:26 +01:00
matchAndRewrite(fir::BoxEleSizeOp boxelesz, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
[flang] Generate TBAA information. This is initial version of TBAA information generation for Flang generated IR. The desired behavior is that TBAA type descriptors are generated for FIR types during FIR to LLVM types conversion, and then TBAA access tags are attached to memory accessing operations when they are converted to LLVM IR dialect. In the initial version the type conversion is not producing TBAA type descriptors, and all memory accesses are just partitioned into two sets of box and non-box accesses, which can never alias. The TBAA generation is enabled by default at >O0 optimization levels. TBAA generation may also be enabled via `apply-tbaa` option of `fir-to-llvm-ir` conversion pass. `-mllvm -disable-tbaa` engineering option allows disabling TBAA generation to override Flang's default (e.g. when -O1 is used). SPEC CPU2006/437.leslie3d speeds up by more than 2x on Icelake. Reviewed By: jeanPerier, clementval Differential Revision: https://reviews.llvm.org/D141820
2023-01-17 09:08:43 -08:00
mlir::Value box = adaptor.getOperands()[0];
[fir] Add fir.box_rank, fir.box_addr, fir.box_dims and fir.box_elesize conversion This patch adds conversion for basic box operations that extract information from the box. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113551 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-10 15:28:26 +01:00
auto loc = boxelesz.getLoc();
auto ty = convertType(boxelesz.getType());
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
TypePair boxTyPair = getBoxTypePair(boxelesz.getVal().getType());
auto elemSize = getElementSizeFromBox(loc, ty, boxTyPair, box, rewriter);
[fir] Add fir.box_isarray, fir.box_isptr and fir.box_isalloc conversion. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113566 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-11 10:39:02 +01:00
rewriter.replaceOp(boxelesz, elemSize);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[fir] Add fir.box_isarray, fir.box_isptr and fir.box_isalloc conversion. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113566 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-11 10:39:02 +01:00
}
};
/// Lower `fir.box_isalloc` to a sequence of operations to determine if the
/// boxed value was from an ALLOCATABLE entity.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct BoxIsAllocOpConversion : public fir::FIROpConversion<fir::BoxIsAllocOp> {
[fir] Add fir.box_isarray, fir.box_isptr and fir.box_isalloc conversion. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113566 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-11 10:39:02 +01:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[fir] Add fir.box_isarray, fir.box_isptr and fir.box_isalloc conversion. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113566 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-11 10:39:02 +01:00
matchAndRewrite(fir::BoxIsAllocOp boxisalloc, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
mlir::Value box = adaptor.getOperands()[0];
auto loc = boxisalloc.getLoc();
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
TypePair boxTyPair = getBoxTypePair(boxisalloc.getVal().getType());
mlir::Value check =
genBoxAttributeCheck(loc, boxTyPair, box, rewriter, kAttrAllocatable);
[fir] Add fir.box_isarray, fir.box_isptr and fir.box_isalloc conversion. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113566 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-11 10:39:02 +01:00
rewriter.replaceOp(boxisalloc, check);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[fir] Add fir.box_isarray, fir.box_isptr and fir.box_isalloc conversion. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113566 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-11 10:39:02 +01:00
}
};
/// Lower `fir.box_isarray` to a sequence of operations to determine if the
/// boxed is an array.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct BoxIsArrayOpConversion : public fir::FIROpConversion<fir::BoxIsArrayOp> {
[fir] Add fir.box_isarray, fir.box_isptr and fir.box_isalloc conversion. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113566 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-11 10:39:02 +01:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[fir] Add fir.box_isarray, fir.box_isptr and fir.box_isalloc conversion. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113566 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-11 10:39:02 +01:00
matchAndRewrite(fir::BoxIsArrayOp boxisarray, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
mlir::Value a = adaptor.getOperands()[0];
auto loc = boxisarray.getLoc();
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
TypePair boxTyPair = getBoxTypePair(boxisarray.getVal().getType());
[flang] update fir.box_rank and fir.is_array codegen (#93541) fir.box_rank codegen was invalid, it was assuming the rank field in the descriptor was an i32. This is not correct. Do not hard code the type, use the named position to find the type, and convert as needed in the patterns.
2024-05-28 17:32:27 +02:00
mlir::Value rank = getRankFromBox(loc, boxTyPair, a, rewriter);
mlir::Value c0 = genConstantIndex(loc, rank.getType(), rewriter, 0);
[fir] Add fir.box_isarray, fir.box_isptr and fir.box_isalloc conversion. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113566 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-11 10:39:02 +01:00
rewriter.replaceOpWithNewOp<mlir::LLVM::ICmpOp>(
boxisarray, mlir::LLVM::ICmpPredicate::ne, rank, c0);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[fir] Add fir.box_isarray, fir.box_isptr and fir.box_isalloc conversion. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113566 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-11 10:39:02 +01:00
}
};
/// Lower `fir.box_isptr` to a sequence of operations to determined if the
/// boxed value was from a POINTER entity.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct BoxIsPtrOpConversion : public fir::FIROpConversion<fir::BoxIsPtrOp> {
[fir] Add fir.box_isarray, fir.box_isptr and fir.box_isalloc conversion. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113566 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-11 10:39:02 +01:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[fir] Add fir.box_isarray, fir.box_isptr and fir.box_isalloc conversion. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113566 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-11 10:39:02 +01:00
matchAndRewrite(fir::BoxIsPtrOp boxisptr, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
mlir::Value box = adaptor.getOperands()[0];
auto loc = boxisptr.getLoc();
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
TypePair boxTyPair = getBoxTypePair(boxisptr.getVal().getType());
mlir::Value check =
genBoxAttributeCheck(loc, boxTyPair, box, rewriter, kAttrPointer);
[fir] Add fir.box_isarray, fir.box_isptr and fir.box_isalloc conversion. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113566 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-11 10:39:02 +01:00
rewriter.replaceOp(boxisptr, check);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[fir] Add fir.box_rank, fir.box_addr, fir.box_dims and fir.box_elesize conversion This patch adds conversion for basic box operations that extract information from the box. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113551 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-10 15:28:26 +01:00
}
};
/// Lower `fir.box_rank` to the sequence of operation to extract the rank from
/// the box.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct BoxRankOpConversion : public fir::FIROpConversion<fir::BoxRankOp> {
[fir] Add fir.box_rank, fir.box_addr, fir.box_dims and fir.box_elesize conversion This patch adds conversion for basic box operations that extract information from the box. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113551 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-10 15:28:26 +01:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[fir] Add fir.box_rank, fir.box_addr, fir.box_dims and fir.box_elesize conversion This patch adds conversion for basic box operations that extract information from the box. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113551 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-10 15:28:26 +01:00
matchAndRewrite(fir::BoxRankOp boxrank, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
mlir::Value a = adaptor.getOperands()[0];
auto loc = boxrank.getLoc();
mlir::Type ty = convertType(boxrank.getType());
[flang] lower RANK intrinsic (#93694) First commit is reviewed in https://github.com/llvm/llvm-project/pull/93682. Lower RANK using fir.box_rank. This patches updates fir.box_rank to accept box reference, this avoids the need of generating an assumed-rank fir.load just for the sake of reading ALLOCATABLE/POINTER rank. The fir.load would generate a "dynamic" memcpy that is hard to optimize without further knowledge. A read effect is conditionally given to the operation.
2024-05-30 11:02:09 +02:00
TypePair boxTyPair =
getBoxTypePair(fir::unwrapRefType(boxrank.getBox().getType()));
[flang] update fir.box_rank and fir.is_array codegen (#93541) fir.box_rank codegen was invalid, it was assuming the rank field in the descriptor was an i32. This is not correct. Do not hard code the type, use the named position to find the type, and convert as needed in the patterns.
2024-05-28 17:32:27 +02:00
mlir::Value rank = getRankFromBox(loc, boxTyPair, a, rewriter);
mlir::Value result = integerCast(loc, rewriter, ty, rank);
[fir] Add fir.box_rank, fir.box_addr, fir.box_dims and fir.box_elesize conversion This patch adds conversion for basic box operations that extract information from the box. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113551 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-10 15:28:26 +01:00
rewriter.replaceOp(boxrank, result);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[fir] Add fir.box_rank, fir.box_addr, fir.box_dims and fir.box_elesize conversion This patch adds conversion for basic box operations that extract information from the box. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113551 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-10 15:28:26 +01:00
}
};
[Flang] Notify conversion failure for Proc ops, types Add the FIR to LLVM conversion patterns for the BoxProcHostOp, EmboxProcOp, and UnboxProcOp ops and the boxproc type. These are currently unimplemented. Implementation will come at a later time when support for Fortran 2003 procedure pointer feature is added. Reviewed By: clementval, rovka Differential Revision: https://reviews.llvm.org/D113879 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-18 11:26:53 +00:00
/// Lower `fir.boxproc_host` operation. Extracts the host pointer from the
/// boxproc.
/// TODO: Part of supporting Fortran 2003 procedure pointers.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct BoxProcHostOpConversion
: public fir::FIROpConversion<fir::BoxProcHostOp> {
[Flang] Notify conversion failure for Proc ops, types Add the FIR to LLVM conversion patterns for the BoxProcHostOp, EmboxProcOp, and UnboxProcOp ops and the boxproc type. These are currently unimplemented. Implementation will come at a later time when support for Fortran 2003 procedure pointer feature is added. Reviewed By: clementval, rovka Differential Revision: https://reviews.llvm.org/D113879 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-18 11:26:53 +00:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] Notify conversion failure for Proc ops, types Add the FIR to LLVM conversion patterns for the BoxProcHostOp, EmboxProcOp, and UnboxProcOp ops and the boxproc type. These are currently unimplemented. Implementation will come at a later time when support for Fortran 2003 procedure pointer feature is added. Reviewed By: clementval, rovka Differential Revision: https://reviews.llvm.org/D113879 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-18 11:26:53 +00:00
matchAndRewrite(fir::BoxProcHostOp boxprochost, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
[Flang] Replace notifyMatchFailure with TODO hard failures For unimplemented patterns we revert to using TODO hard failures instead of notifyMatchFailure. For fir.select_type revert to using mlir::emiterror. For the fir.embox TODO on a type with len params we cannot add a test since the type cannot be converted to llvm. Adding negative tests using not and checking for the error message. TODO exits with an error in a build without assertion but aborts in a build with assertions. Abort requires using not with the --crash option. The two different usages of not is handled by using a custom command %not_todo_cmd which is converted to not or not --crash depending on the presence or absence of assertions. Using llvm-config to check the presence of assertions. Reviewed By: clementval, awarzynski Differential Revision: https://reviews.llvm.org/D114371
2021-12-01 22:12:12 +00:00
TODO(boxprochost.getLoc(), "fir.boxproc_host codegen");
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::failure();
[Flang] Notify conversion failure for Proc ops, types Add the FIR to LLVM conversion patterns for the BoxProcHostOp, EmboxProcOp, and UnboxProcOp ops and the boxproc type. These are currently unimplemented. Implementation will come at a later time when support for Fortran 2003 procedure pointer feature is added. Reviewed By: clementval, rovka Differential Revision: https://reviews.llvm.org/D113879 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-18 11:26:53 +00:00
}
};
[fir] Add fir.box_tdesc conversion This patch adds the conversion pattern for `fir.box_tdes`. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113931 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-17 12:01:57 +01:00
/// Lower `fir.box_tdesc` to the sequence of operations to extract the type
/// descriptor from the box.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct BoxTypeDescOpConversion
: public fir::FIROpConversion<fir::BoxTypeDescOp> {
[fir] Add fir.box_tdesc conversion This patch adds the conversion pattern for `fir.box_tdes`. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113931 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-17 12:01:57 +01:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[fir] Add fir.box_tdesc conversion This patch adds the conversion pattern for `fir.box_tdes`. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113931 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-17 12:01:57 +01:00
matchAndRewrite(fir::BoxTypeDescOp boxtypedesc, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
mlir::Value box = adaptor.getOperands()[0];
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
TypePair boxTyPair = getBoxTypePair(boxtypedesc.getBox().getType());
auto typeDescAddr =
loadTypeDescAddress(boxtypedesc.getLoc(), boxTyPair, box, rewriter);
[flang] Use tdesc on fir.embox in code generation For polymoprhic entities, the type descriptor is dynamic. The tdesc operand on fir.embox is meant to propagate the dynamic type when embox a polymorphic entity. This patch makes use of this operand in code generation and update the created descriptor accordingly. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D136748
2022-10-26 14:16:43 +02:00
rewriter.replaceOp(boxtypedesc, typeDescAddr);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[fir] Add fir.box_tdesc conversion This patch adds the conversion pattern for `fir.box_tdes`. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113931 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-17 12:01:57 +01:00
}
};
[flang] Add fir.box_typecode operation `fir.box_typecode` operation allows to retrieve the type code from a boxed value. This will be used in the `fir.select_type` conversion to if-then-else ladder for type guard statement with intrinsic type spec instead of using a runtime call. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D137829
2022-11-14 10:50:56 +01:00
/// Lower `fir.box_typecode` to a sequence of operations to extract the type
/// code in the boxed value.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct BoxTypeCodeOpConversion
: public fir::FIROpConversion<fir::BoxTypeCodeOp> {
[flang] Add fir.box_typecode operation `fir.box_typecode` operation allows to retrieve the type code from a boxed value. This will be used in the `fir.select_type` conversion to if-then-else ladder for type guard statement with intrinsic type spec instead of using a runtime call. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D137829
2022-11-14 10:50:56 +01:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[flang] Add fir.box_typecode operation `fir.box_typecode` operation allows to retrieve the type code from a boxed value. This will be used in the `fir.select_type` conversion to if-then-else ladder for type guard statement with intrinsic type spec instead of using a runtime call. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D137829
2022-11-14 10:50:56 +01:00
matchAndRewrite(fir::BoxTypeCodeOp op, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
mlir::Value box = adaptor.getOperands()[0];
auto loc = box.getLoc();
auto ty = convertType(op.getType());
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
TypePair boxTyPair = getBoxTypePair(op.getBox().getType());
auto typeCode =
getValueFromBox(loc, boxTyPair, box, ty, rewriter, kTypePosInBox);
[flang] Add fir.box_typecode operation `fir.box_typecode` operation allows to retrieve the type code from a boxed value. This will be used in the `fir.select_type` conversion to if-then-else ladder for type guard statement with intrinsic type spec instead of using a runtime call. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D137829
2022-11-14 10:50:56 +01:00
rewriter.replaceOp(op, typeCode);
return mlir::success();
}
};
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// Lower `fir.string_lit` to LLVM IR dialect operation.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct StringLitOpConversion : public fir::FIROpConversion<fir::StringLitOp> {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::StringLitOp constop, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
auto ty = convertType(constop.getType());
auto attr = constop.getValue();
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (mlir::isa<mlir::StringAttr>(attr)) {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
rewriter.replaceOpWithNewOp<mlir::LLVM::ConstantOp>(constop, ty, attr);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
auto charTy = mlir::cast<fir::CharacterType>(constop.getType());
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
unsigned bits = lowerTy().characterBitsize(charTy);
mlir::Type intTy = rewriter.getIntegerType(bits);
[flang] Add global and global box initialization tests This patch addes some global initialization and global box initialization tests. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D122881 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2022-04-03 15:19:38 +02:00
mlir::Location loc = constop.getLoc();
mlir::Value cst = rewriter.create<mlir::LLVM::UndefOp>(loc, ty);
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (auto arr = mlir::dyn_cast<mlir::DenseElementsAttr>(attr)) {
[flang] Add global and global box initialization tests This patch addes some global initialization and global box initialization tests. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D122881 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2022-04-03 15:19:38 +02:00
cst = rewriter.create<mlir::LLVM::ConstantOp>(loc, ty, arr);
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
} else if (auto arr = mlir::dyn_cast<mlir::ArrayAttr>(attr)) {
[flang] Revert changes (NFC)
2022-08-09 16:10:21 -04:00
for (auto a : llvm::enumerate(arr.getValue())) {
[flang] Add global and global box initialization tests This patch addes some global initialization and global box initialization tests. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D122881 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2022-04-03 15:19:38 +02:00
// convert each character to a precise bitsize
[flang] Revert changes (NFC)
2022-08-09 16:10:21 -04:00
auto elemAttr = mlir::IntegerAttr::get(
intTy,
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
mlir::cast<mlir::IntegerAttr>(a.value()).getValue().zextOrTrunc(
bits));
[flang] Revert changes (NFC)
2022-08-09 16:10:21 -04:00
auto elemCst =
rewriter.create<mlir::LLVM::ConstantOp>(loc, intTy, elemAttr);
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
cst = rewriter.create<mlir::LLVM::InsertValueOp>(loc, cst, elemCst,
a.index());
[flang] Add global and global box initialization tests This patch addes some global initialization and global box initialization tests. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D122881 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2022-04-03 15:19:38 +02:00
}
} else {
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::failure();
[flang] Add global and global box initialization tests This patch addes some global initialization and global box initialization tests. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D122881 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2022-04-03 15:19:38 +02:00
}
rewriter.replaceOp(constop, cst);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
};
[flang][NFC] Fix some formatting Fix some mismatch in format used in the file and reduce the diff with fir-dev to be able to finish the upstreaming on this file. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: PeteSteinfeld, kiranchandramohan Differential Revision: https://reviews.llvm.org/D127849
2022-06-15 16:48:46 +02:00
/// `fir.call` -> `llvm.call`
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct CallOpConversion : public fir::FIROpConversion<fir::CallOp> {
[flang][CodeGen] Transform `fir.call` to `llvm.call` This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.call` to `llvm.call`. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Patch originally written by: Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com> Differential Revision: https://reviews.llvm.org/D113278
2021-11-05 13:41:39 +00:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[flang][CodeGen] Transform `fir.call` to `llvm.call` This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.call` to `llvm.call`. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Patch originally written by: Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com> Differential Revision: https://reviews.llvm.org/D113278
2021-11-05 13:41:39 +00:00
matchAndRewrite(fir::CallOp call, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
llvm::SmallVector<mlir::Type> resultTys;
Reland "[flang] Set LLVM specific attributes to fir.call's of Fortran runtime. (#128093)" This change is inspired by a case in facerec benchmark, where performance of scalar code may improve by about 6%@aarch64 due to getting rid of redundant loads from Fortran descriptors. These descriptors are corresponding to subroutine local ALLOCATABLE, SAVE variables. The scalar loop nest in LocalMove subroutine contains call to Fortran runtime IO functions, and LLVM globals-aa analysis cannot prove that these calls do not modify the globalized descriptors with internal linkage. This patch sets and propagates llvm.memory_effects attribute for fir.call operations calling Fortran runtime functions. In particular, it tries to set the Other memory effect to NoModRef. The Other memory effect includes accesses to globals and captured pointers, so we cannot set it for functions taking Fortran descriptors with one exception for calls where the Fortran descriptor arguments are all null. As long as different calls to the same Fortran runtime function may have different attributes, I decided to attach the attributes to the calls rather than functions. Moreover, attaching the attributes to func.func will require propagating these attributes to llvm.func, which is not happening right now. In addition to llvm.memory_effects, the new pass sets llvm.nosync and llvm.nocallback attributes that may also help LLVM alias analysis (e.g. see #127707). These attributes are ignored currently. I will support them in LLVM IR dialect in a separate patch. I also added another pass for developers to be able to print declarations/calls of all Fortran runtime functions that are recognized by the attributes setting pass. It should help with maintenance of the LIT tests.
2025-02-24 09:27:48 -08:00
mlir::Attribute memAttr =
call->getAttr(fir::FIROpsDialect::getFirCallMemoryAttrName());
if (memAttr)
call->removeAttr(fir::FIROpsDialect::getFirCallMemoryAttrName());
[flang][CodeGen] Transform `fir.call` to `llvm.call` This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.call` to `llvm.call`. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Patch originally written by: Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com> Differential Revision: https://reviews.llvm.org/D113278
2021-11-05 13:41:39 +00:00
for (auto r : call.getResults())
resultTys.push_back(convertType(r.getType()));
[flang] Support arith::FastMathFlagsAttr for fir::CallOp. The main purpose of this patch is to propagate fastmath attribute to SimplifyIntrinsicsPass, so that the inline code can inherit the call operation's attributes. Even though I added translation of fastmath from fir::CallOp to LLVM::CallOp, there are no fastmath attributes in LLVM IR. It looks like the translation drops it. This will need additional commits. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D137602
2022-11-09 15:18:50 -08:00
// Convert arith::FastMathFlagsAttr to LLVM::FastMathFlagsAttr.
mlir::arith::AttrConvertFastMathToLLVM<fir::CallOp, mlir::LLVM::CallOp>
attrConvert(call);
[flang][FIR] handle argument attributes in fir.call (#126711) Add pretty printer/parser for fir.call argument/result attributes and propagate them to llvm.call. This will allow implementing the TODO about ABI relevant argument attribute in indirect calls.
2025-02-12 09:49:52 +01:00
auto llvmCall = rewriter.replaceOpWithNewOp<mlir::LLVM::CallOp>(
[mlir][LLVM] Add operand bundle support (#108933) This PR adds LLVM [operand bundle](https://llvm.org/docs/LangRef.html#operand-bundles) support to MLIR LLVM dialect. It affects these 3 operations related to making function calls: `llvm.call`, `llvm.invoke`, and `llvm.call_intrinsic`. This PR adds two new parameters to each of the 3 operations. The first parameter is a variadic operand `op_bundle_operands` that contains the SSA values for operand bundles. The second parameter is a property `op_bundle_tags` which holds an array of strings that represent the tags of each operand bundle.
2024-09-26 13:59:37 +08:00
call, resultTys, adaptor.getOperands(),
addLLVMOpBundleAttrs(rewriter, attrConvert.getAttrs(),
adaptor.getOperands().size()));
[flang] add ABI argument attributes in indirect calls (#126896) Last piece that implements the TODO for sret and byval setting on indirect calls. This includes a fix to the codegen last patch. I thought types in in type attributes were automatically converted in dialect conversion passes, but that is not the case. The sret and byval type needs to be converted to llvm types in codegen (mlir FuncOp conversion is doing a similar conversion).
2025-02-12 17:31:34 +01:00
if (mlir::ArrayAttr argAttrsArray = call.getArgAttrsAttr()) {
// sret and byval type needs to be converted.
auto convertTypeAttr = [&](const mlir::NamedAttribute &attr) {
return mlir::TypeAttr::get(convertType(
llvm::cast<mlir::TypeAttr>(attr.getValue()).getValue()));
};
llvm::SmallVector<mlir::Attribute> newArgAttrsArray;
for (auto argAttrs : argAttrsArray) {
llvm::SmallVector<mlir::NamedAttribute> convertedAttrs;
for (const mlir::NamedAttribute &attr :
llvm::cast<mlir::DictionaryAttr>(argAttrs)) {
if (attr.getName().getValue() ==
mlir::LLVM::LLVMDialect::getByValAttrName()) {
convertedAttrs.push_back(rewriter.getNamedAttr(
mlir::LLVM::LLVMDialect::getByValAttrName(),
convertTypeAttr(attr)));
} else if (attr.getName().getValue() ==
mlir::LLVM::LLVMDialect::getStructRetAttrName()) {
convertedAttrs.push_back(rewriter.getNamedAttr(
mlir::LLVM::LLVMDialect::getStructRetAttrName(),
convertTypeAttr(attr)));
} else {
convertedAttrs.push_back(attr);
}
}
newArgAttrsArray.emplace_back(
mlir::DictionaryAttr::get(rewriter.getContext(), convertedAttrs));
}
llvmCall.setArgAttrsAttr(rewriter.getArrayAttr(newArgAttrsArray));
}
[flang][FIR] handle argument attributes in fir.call (#126711) Add pretty printer/parser for fir.call argument/result attributes and propagate them to llvm.call. This will allow implementing the TODO about ABI relevant argument attribute in indirect calls.
2025-02-12 09:49:52 +01:00
if (mlir::ArrayAttr resAttrs = call.getResAttrsAttr())
llvmCall.setResAttrsAttr(resAttrs);
Reland "[flang] Set LLVM specific attributes to fir.call's of Fortran runtime. (#128093)" This change is inspired by a case in facerec benchmark, where performance of scalar code may improve by about 6%@aarch64 due to getting rid of redundant loads from Fortran descriptors. These descriptors are corresponding to subroutine local ALLOCATABLE, SAVE variables. The scalar loop nest in LocalMove subroutine contains call to Fortran runtime IO functions, and LLVM globals-aa analysis cannot prove that these calls do not modify the globalized descriptors with internal linkage. This patch sets and propagates llvm.memory_effects attribute for fir.call operations calling Fortran runtime functions. In particular, it tries to set the Other memory effect to NoModRef. The Other memory effect includes accesses to globals and captured pointers, so we cannot set it for functions taking Fortran descriptors with one exception for calls where the Fortran descriptor arguments are all null. As long as different calls to the same Fortran runtime function may have different attributes, I decided to attach the attributes to the calls rather than functions. Moreover, attaching the attributes to func.func will require propagating these attributes to llvm.func, which is not happening right now. In addition to llvm.memory_effects, the new pass sets llvm.nosync and llvm.nocallback attributes that may also help LLVM alias analysis (e.g. see #127707). These attributes are ignored currently. I will support them in LLVM IR dialect in a separate patch. I also added another pass for developers to be able to print declarations/calls of all Fortran runtime functions that are recognized by the attributes setting pass. It should help with maintenance of the LIT tests.
2025-02-24 09:27:48 -08:00
if (memAttr)
llvmCall.setMemoryEffectsAttr(
mlir::cast<mlir::LLVM::MemoryEffectsAttr>(memAttr));
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[flang][CodeGen] Transform `fir.call` to `llvm.call` This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.call` to `llvm.call`. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Patch originally written by: Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com> Differential Revision: https://reviews.llvm.org/D113278
2021-11-05 13:41:39 +00:00
}
};
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
} // namespace
[flang][CodeGen] Transform `fir.call` to `llvm.call` This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.call` to `llvm.call`. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Patch originally written by: Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com> Differential Revision: https://reviews.llvm.org/D113278
2021-11-05 13:41:39 +00:00
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
static mlir::Type getComplexEleTy(mlir::Type complex) {
[flang][FIR] remove fir.complex type and its fir.real element type (#111025) Final patch of https://discourse.llvm.org/t/rfc-flang-replace-usages-of-fir-complex-by-mlir-complex-type/82292 Since fir.real was only still used as fir.complex element type, this patch removes it at the same time.
2024-10-04 09:57:03 +02:00
return mlir::cast<mlir::ComplexType>(complex).getElementType();
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
}
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
namespace {
[fir] Add fir.cmpc conversion This patch adds the codegen for fir.cmpc. The real and imaginary parts are extracted and compared separately. For the .EQ. predicate the results are AND'd, for the .NE. predicate the results are OR'd, and for other predicates we keep only the result on the real parts. This patch is part of the upstreaming effort from fir-dev. Differential Revision: https://reviews.llvm.org/D113976 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-16 10:17:29 +00:00
/// Compare complex values
///
/// Per 10.1, the only comparisons available are .EQ. (oeq) and .NE. (une).
///
/// For completeness, all other comparison are done on the real component only.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct CmpcOpConversion : public fir::FIROpConversion<fir::CmpcOp> {
[fir] Add fir.cmpc conversion This patch adds the codegen for fir.cmpc. The real and imaginary parts are extracted and compared separately. For the .EQ. predicate the results are AND'd, for the .NE. predicate the results are OR'd, and for other predicates we keep only the result on the real parts. This patch is part of the upstreaming effort from fir-dev. Differential Revision: https://reviews.llvm.org/D113976 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-16 10:17:29 +00:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[fir] Add fir.cmpc conversion This patch adds the codegen for fir.cmpc. The real and imaginary parts are extracted and compared separately. For the .EQ. predicate the results are AND'd, for the .NE. predicate the results are OR'd, and for other predicates we keep only the result on the real parts. This patch is part of the upstreaming effort from fir-dev. Differential Revision: https://reviews.llvm.org/D113976 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-16 10:17:29 +00:00
matchAndRewrite(fir::CmpcOp cmp, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
mlir::ValueRange operands = adaptor.getOperands();
mlir::Type resTy = convertType(cmp.getType());
mlir::Location loc = cmp.getLoc();
[mlir][flang] add fast math attribute to fcmp (#74315) `llvm.fcmp` does support fast math attributes therefore so should `arith.cmpf`. The heavy churn in flang tests are because flang sets `fastmath<contract>` by default on all operations that support the fast math interface. Downstream users of MLIR should not be so effected. This was requested in https://github.com/llvm/llvm-project/issues/74263
2023-12-06 10:19:48 +00:00
mlir::LLVM::FastmathFlags fmf =
mlir::arith::convertArithFastMathFlagsToLLVM(cmp.getFastmath());
mlir::LLVM::FCmpPredicate pred =
static_cast<mlir::LLVM::FCmpPredicate>(cmp.getPredicate());
auto rcp = rewriter.create<mlir::LLVM::FCmpOp>(
loc, resTy, pred,
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
rewriter.create<mlir::LLVM::ExtractValueOp>(loc, operands[0], 0),
[mlir][flang] add fast math attribute to fcmp (#74315) `llvm.fcmp` does support fast math attributes therefore so should `arith.cmpf`. The heavy churn in flang tests are because flang sets `fastmath<contract>` by default on all operations that support the fast math interface. Downstream users of MLIR should not be so effected. This was requested in https://github.com/llvm/llvm-project/issues/74263
2023-12-06 10:19:48 +00:00
rewriter.create<mlir::LLVM::ExtractValueOp>(loc, operands[1], 0), fmf);
auto icp = rewriter.create<mlir::LLVM::FCmpOp>(
loc, resTy, pred,
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
rewriter.create<mlir::LLVM::ExtractValueOp>(loc, operands[0], 1),
[mlir][flang] add fast math attribute to fcmp (#74315) `llvm.fcmp` does support fast math attributes therefore so should `arith.cmpf`. The heavy churn in flang tests are because flang sets `fastmath<contract>` by default on all operations that support the fast math interface. Downstream users of MLIR should not be so effected. This was requested in https://github.com/llvm/llvm-project/issues/74263
2023-12-06 10:19:48 +00:00
rewriter.create<mlir::LLVM::ExtractValueOp>(loc, operands[1], 1), fmf);
[flang][NFC] Fix some formatting Fix some mismatch in format used in the file and reduce the diff with fir-dev to be able to finish the upstreaming on this file. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: PeteSteinfeld, kiranchandramohan Differential Revision: https://reviews.llvm.org/D127849
2022-06-15 16:48:46 +02:00
llvm::SmallVector<mlir::Value, 2> cp = {rcp, icp};
[fir] Add fir.cmpc conversion This patch adds the codegen for fir.cmpc. The real and imaginary parts are extracted and compared separately. For the .EQ. predicate the results are AND'd, for the .NE. predicate the results are OR'd, and for other predicates we keep only the result on the real parts. This patch is part of the upstreaming effort from fir-dev. Differential Revision: https://reviews.llvm.org/D113976 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-16 10:17:29 +00:00
switch (cmp.getPredicate()) {
case mlir::arith::CmpFPredicate::OEQ: // .EQ.
rewriter.replaceOpWithNewOp<mlir::LLVM::AndOp>(cmp, resTy, cp);
break;
case mlir::arith::CmpFPredicate::UNE: // .NE.
rewriter.replaceOpWithNewOp<mlir::LLVM::OrOp>(cmp, resTy, cp);
break;
default:
rewriter.replaceOp(cmp, rcp.getResult());
break;
}
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[fir] Add fir.cmpc conversion This patch adds the codegen for fir.cmpc. The real and imaginary parts are extracted and compared separately. For the .EQ. predicate the results are AND'd, for the .NE. predicate the results are OR'd, and for other predicates we keep only the result on the real parts. This patch is part of the upstreaming effort from fir-dev. Differential Revision: https://reviews.llvm.org/D113976 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-16 10:17:29 +00:00
}
};
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
/// convert value of from-type to value of to-type
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct ConvertOpConversion : public fir::FIROpConversion<fir::ConvertOp> {
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
using FIROpConversion::FIROpConversion;
static bool isFloatingPointTy(mlir::Type ty) {
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
return mlir::isa<mlir::FloatType>(ty);
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
}
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
matchAndRewrite(fir::ConvertOp convert, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
[flang] Use unix logical representation for fir.logical The front-end and the runtime are currently using the unix logical representation, but lowering was not. These inconsistencies could caused issues. The only place that defines what the logical representation is in lowering is the translation from FIR to LLVM (FIR is agnostic to the actual representation). More precisely, the LLVM implementation of `fir.convert` between `i1` and `fir.logcial` is what defines the representation: - `fir.convert` from `i1` to `fir.logical` defines the `.true.` and `.false.` canonical representations - `fir.convert` from `fir.logical` to `i1` decides what the test for truth is. Unix representation is: - .true. canonical integer representation is 1 - .false. canonical integer representation is 0 - the test for truth is "integer representation != 0" For the record, the previous representation that was used was in codegen was: - .true. canonical integer representation is -1 (all bits 1) - .false. canonical integer representation is 0 - the test for truth is "integer representation lowest bit == 1" Differential Revision: https://reviews.llvm.org/D121200
2022-03-09 09:41:55 +01:00
auto fromFirTy = convert.getValue().getType();
auto toFirTy = convert.getRes().getType();
auto fromTy = convertType(fromFirTy);
auto toTy = convertType(toFirTy);
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
mlir::Value op0 = adaptor.getOperands()[0];
[flang] Normalize logical values during type conversions. Flang was missing value normalization for logical<->integer conversions which is required by Flang specification. The shrinking logical<->logical conversions were also incorrectly truncating the input. This change performs value normalization for all logical<->integer conversions and logical<->logical conversions between different kinds. Note that value normalization is not strictly required for logical(kind=k1)->logical(kind=k2) conversions when k1 < k2. Differential Revision: https://reviews.llvm.org/D147019
2023-03-27 19:28:36 -07:00
if (fromFirTy == toFirTy) {
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
rewriter.replaceOp(convert, op0);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
}
[flang] Normalize logical values during type conversions. Flang was missing value normalization for logical<->integer conversions which is required by Flang specification. The shrinking logical<->logical conversions were also incorrectly truncating the input. This change performs value normalization for all logical<->integer conversions and logical<->logical conversions between different kinds. Note that value normalization is not strictly required for logical(kind=k1)->logical(kind=k2) conversions when k1 < k2. Differential Revision: https://reviews.llvm.org/D147019
2023-03-27 19:28:36 -07:00
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
auto loc = convert.getLoc();
[flang] Normalize logical values during type conversions. Flang was missing value normalization for logical<->integer conversions which is required by Flang specification. The shrinking logical<->logical conversions were also incorrectly truncating the input. This change performs value normalization for all logical<->integer conversions and logical<->logical conversions between different kinds. Note that value normalization is not strictly required for logical(kind=k1)->logical(kind=k2) conversions when k1 < k2. Differential Revision: https://reviews.llvm.org/D147019
2023-03-27 19:28:36 -07:00
auto i1Type = mlir::IntegerType::get(convert.getContext(), 1);
[flang] Implement conversion of compatible derived types (#111165) With some restrictions, BIND(C) derived types can be converted to compatible BIND(C) derived types. Semantics already support this, but ConvertOp was missing the conversion of such types. Fixes https://github.com/llvm/llvm-project/issues/107783
2024-10-09 10:37:46 -03:00
if (mlir::isa<fir::RecordType>(toFirTy)) {
// Convert to compatible BIND(C) record type.
// Double check that the record types are compatible (it should have
// already been checked by the verifier).
assert(mlir::cast<fir::RecordType>(fromFirTy).getTypeList() ==
mlir::cast<fir::RecordType>(toFirTy).getTypeList() &&
"incompatible record types");
auto toStTy = mlir::cast<mlir::LLVM::LLVMStructType>(toTy);
mlir::Value val = rewriter.create<mlir::LLVM::UndefOp>(loc, toStTy);
auto indexTypeMap = toStTy.getSubelementIndexMap();
assert(indexTypeMap.has_value() && "invalid record type");
for (auto [attr, type] : indexTypeMap.value()) {
int64_t index = mlir::cast<mlir::IntegerAttr>(attr).getInt();
auto extVal =
rewriter.create<mlir::LLVM::ExtractValueOp>(loc, op0, index);
val =
rewriter.create<mlir::LLVM::InsertValueOp>(loc, val, extVal, index);
}
rewriter.replaceOp(convert, val);
return mlir::success();
}
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (mlir::isa<fir::LogicalType>(fromFirTy) ||
mlir::isa<fir::LogicalType>(toFirTy)) {
[flang] Normalize logical values during type conversions. Flang was missing value normalization for logical<->integer conversions which is required by Flang specification. The shrinking logical<->logical conversions were also incorrectly truncating the input. This change performs value normalization for all logical<->integer conversions and logical<->logical conversions between different kinds. Note that value normalization is not strictly required for logical(kind=k1)->logical(kind=k2) conversions when k1 < k2. Differential Revision: https://reviews.llvm.org/D147019
2023-03-27 19:28:36 -07:00
// By specification fir::LogicalType value may be any number,
// where non-zero value represents .true. and zero value represents
// .false.
//
// integer<->logical conversion requires value normalization.
// Conversion from wide logical to narrow logical must set the result
// to non-zero iff the input is non-zero - the easiest way to implement
// it is to compare the input agains zero and set the result to
// the canonical 0/1.
// Conversion from narrow logical to wide logical may be implemented
// as a zero or sign extension of the input, but it may use value
// normalization as well.
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (!mlir::isa<mlir::IntegerType>(fromTy) ||
!mlir::isa<mlir::IntegerType>(toTy))
[flang] Normalize logical values during type conversions. Flang was missing value normalization for logical<->integer conversions which is required by Flang specification. The shrinking logical<->logical conversions were also incorrectly truncating the input. This change performs value normalization for all logical<->integer conversions and logical<->logical conversions between different kinds. Note that value normalization is not strictly required for logical(kind=k1)->logical(kind=k2) conversions when k1 < k2. Differential Revision: https://reviews.llvm.org/D147019
2023-03-27 19:28:36 -07:00
return mlir::emitError(loc)
<< "unsupported types for logical conversion: " << fromTy
<< " -> " << toTy;
// Do folding for constant inputs.
[flang][NFC] Unify getIfConstantIntValue helpers (#87633) There were different helpers for attempting to fetch compile time constants from MLIR: one in fir::getIntIfConstant and one in CodeGen. Unify the two.
2024-04-05 12:39:24 +01:00
if (auto constVal = fir::getIntIfConstant(op0)) {
[flang] Normalize logical values during type conversions. Flang was missing value normalization for logical<->integer conversions which is required by Flang specification. The shrinking logical<->logical conversions were also incorrectly truncating the input. This change performs value normalization for all logical<->integer conversions and logical<->logical conversions between different kinds. Note that value normalization is not strictly required for logical(kind=k1)->logical(kind=k2) conversions when k1 < k2. Differential Revision: https://reviews.llvm.org/D147019
2023-03-27 19:28:36 -07:00
mlir::Value normVal =
genConstantIndex(loc, toTy, rewriter, *constVal ? 1 : 0);
rewriter.replaceOp(convert, normVal);
return mlir::success();
}
// If the input is i1, then we can just zero extend it, and
// the result will be normalized.
if (fromTy == i1Type) {
rewriter.replaceOpWithNewOp<mlir::LLVM::ZExtOp>(convert, toTy, op0);
return mlir::success();
}
// Compare the input with zero.
mlir::Value zero = genConstantIndex(loc, fromTy, rewriter, 0);
auto isTrue = rewriter.create<mlir::LLVM::ICmpOp>(
loc, mlir::LLVM::ICmpPredicate::ne, op0, zero);
// Zero extend the i1 isTrue result to the required type (unless it is i1
// itself).
if (toTy != i1Type)
rewriter.replaceOpWithNewOp<mlir::LLVM::ZExtOp>(convert, toTy, isTrue);
else
rewriter.replaceOp(convert, isTrue.getResult());
return mlir::success();
}
if (fromTy == toTy) {
rewriter.replaceOp(convert, op0);
return mlir::success();
}
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
auto convertFpToFp = [&](mlir::Value val, unsigned fromBits,
unsigned toBits, mlir::Type toTy) -> mlir::Value {
if (fromBits == toBits) {
// TODO: Converting between two floating-point representations with the
// same bitwidth is not allowed for now.
mlir::emitError(loc,
"cannot implicitly convert between two floating-point "
"representations of the same bitwidth");
return {};
}
if (fromBits > toBits)
return rewriter.create<mlir::LLVM::FPTruncOp>(loc, toTy, val);
return rewriter.create<mlir::LLVM::FPExtOp>(loc, toTy, val);
};
// Complex to complex conversion.
[flang] Use unix logical representation for fir.logical The front-end and the runtime are currently using the unix logical representation, but lowering was not. These inconsistencies could caused issues. The only place that defines what the logical representation is in lowering is the translation from FIR to LLVM (FIR is agnostic to the actual representation). More precisely, the LLVM implementation of `fir.convert` between `i1` and `fir.logcial` is what defines the representation: - `fir.convert` from `i1` to `fir.logical` defines the `.true.` and `.false.` canonical representations - `fir.convert` from `fir.logical` to `i1` decides what the test for truth is. Unix representation is: - .true. canonical integer representation is 1 - .false. canonical integer representation is 0 - the test for truth is "integer representation != 0" For the record, the previous representation that was used was in codegen was: - .true. canonical integer representation is -1 (all bits 1) - .false. canonical integer representation is 0 - the test for truth is "integer representation lowest bit == 1" Differential Revision: https://reviews.llvm.org/D121200
2022-03-09 09:41:55 +01:00
if (fir::isa_complex(fromFirTy) && fir::isa_complex(toFirTy)) {
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
// Special case: handle the conversion of a complex such that both the
// real and imaginary parts are converted together.
[flang][mlir][NFC] Replace uses of raw accessors with prefixed accessors `kEmitAccessorPrefix_Raw ` is being removed, and so updating the accessors to `kEmitAccessorPrefix_Prefixed`. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D119812
2022-02-15 20:35:46 +05:30
auto ty = convertType(getComplexEleTy(convert.getValue().getType()));
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
auto rp = rewriter.create<mlir::LLVM::ExtractValueOp>(loc, op0, 0);
auto ip = rewriter.create<mlir::LLVM::ExtractValueOp>(loc, op0, 1);
[flang][mlir][NFC] Replace uses of raw accessors with prefixed accessors `kEmitAccessorPrefix_Raw ` is being removed, and so updating the accessors to `kEmitAccessorPrefix_Prefixed`. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D119812
2022-02-15 20:35:46 +05:30
auto nt = convertType(getComplexEleTy(convert.getRes().getType()));
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
auto fromBits = mlir::LLVM::getPrimitiveTypeSizeInBits(ty);
auto toBits = mlir::LLVM::getPrimitiveTypeSizeInBits(nt);
auto rc = convertFpToFp(rp, fromBits, toBits, nt);
auto ic = convertFpToFp(ip, fromBits, toBits, nt);
auto un = rewriter.create<mlir::LLVM::UndefOp>(loc, toTy);
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
auto i1 = rewriter.create<mlir::LLVM::InsertValueOp>(loc, un, rc, 0);
rewriter.replaceOpWithNewOp<mlir::LLVM::InsertValueOp>(convert, i1, ic,
1);
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
return mlir::success();
}
[flang] Use unix logical representation for fir.logical The front-end and the runtime are currently using the unix logical representation, but lowering was not. These inconsistencies could caused issues. The only place that defines what the logical representation is in lowering is the translation from FIR to LLVM (FIR is agnostic to the actual representation). More precisely, the LLVM implementation of `fir.convert` between `i1` and `fir.logcial` is what defines the representation: - `fir.convert` from `i1` to `fir.logical` defines the `.true.` and `.false.` canonical representations - `fir.convert` from `fir.logical` to `i1` decides what the test for truth is. Unix representation is: - .true. canonical integer representation is 1 - .false. canonical integer representation is 0 - the test for truth is "integer representation != 0" For the record, the previous representation that was used was in codegen was: - .true. canonical integer representation is -1 (all bits 1) - .false. canonical integer representation is 0 - the test for truth is "integer representation lowest bit == 1" Differential Revision: https://reviews.llvm.org/D121200
2022-03-09 09:41:55 +01:00
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
// Floating point to floating point conversion.
if (isFloatingPointTy(fromTy)) {
if (isFloatingPointTy(toTy)) {
auto fromBits = mlir::LLVM::getPrimitiveTypeSizeInBits(fromTy);
auto toBits = mlir::LLVM::getPrimitiveTypeSizeInBits(toTy);
auto v = convertFpToFp(op0, fromBits, toBits, toTy);
rewriter.replaceOp(convert, v);
return mlir::success();
}
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (mlir::isa<mlir::IntegerType>(toTy)) {
[flang] Use saturated intrinsics for floating point to integer conversions (#130686) The saturated floating point conversion intrinsics match the semantics in the standard more closely than the fptosi/fptoui instructions. Case 2 of 16.9.100 is > INT (A [, KIND]) > If A is of type real, there are two cases: if |A| < 1, INT (A) has the value 0; if |A| ≥ 1, INT (A) is the integer whose magnitude is the largest integer that does not exceed the magnitude of A and whose sign is the same as the sign of A. Currently, converting a floating point value into an integer type too small to hold the constant will be converted to poison in opt, leaving us with garbage: ``` > cat t.f90 program main real(kind=16) :: f integer(kind=4) :: i f=huge(f) i=f print *, i end program main # current upstream > for i in `seq 10`; do; ./a.out; done -862156992 -1497393344 -739096768 -1649494208 1761228608 -1959270592 -746244288 -1629194432 -231217344 382322496 ``` With the saturated fptoui/fptosi intrinsics, we get the appropriate values ``` # mine > flang -O2 ./t.f90 && ./a.out 2147483647 > perl -e 'printf "%d\n", (2 ** 31) - 1' 2147483647 ``` One notable difference: NaNs being converted to ints will become zero, unlike current flang (and some other compilers). Newer versions of GCC have this behavior.
2025-03-12 08:14:46 -07:00
// NOTE: We are checking the fir type here because toTy is an LLVM type
// which is signless, and we need to use the intrinsic that matches the
// sign of the output in fir.
if (toFirTy.isUnsignedInteger()) {
auto intrinsicName =
mlir::StringAttr::get(convert.getContext(), "llvm.fptoui.sat");
rewriter.replaceOpWithNewOp<mlir::LLVM::CallIntrinsicOp>(
convert, toTy, intrinsicName, op0);
} else {
auto intrinsicName =
mlir::StringAttr::get(convert.getContext(), "llvm.fptosi.sat");
rewriter.replaceOpWithNewOp<mlir::LLVM::CallIntrinsicOp>(
convert, toTy, intrinsicName, op0);
}
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
return mlir::success();
}
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
} else if (mlir::isa<mlir::IntegerType>(fromTy)) {
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
// Integer to integer conversion.
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (mlir::isa<mlir::IntegerType>(toTy)) {
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
auto fromBits = mlir::LLVM::getPrimitiveTypeSizeInBits(fromTy);
auto toBits = mlir::LLVM::getPrimitiveTypeSizeInBits(toTy);
assert(fromBits != toBits);
if (fromBits > toBits) {
rewriter.replaceOpWithNewOp<mlir::LLVM::TruncOp>(convert, toTy, op0);
return mlir::success();
}
[flang] Add UNSIGNED (#113504) Implement the UNSIGNED extension type and operations under control of a language feature flag (-funsigned). This is nearly identical to the UNSIGNED feature that has been available in Sun Fortran for years, and now implemented in GNU Fortran for gfortran 15, and proposed for ISO standardization in J3/24-116.txt. See the new documentation for details; but in short, this is C's unsigned type, with guaranteed modular arithmetic for +, -, and *, and the related transformational intrinsic functions SUM & al.
2024-12-18 07:02:37 -08:00
if (fromFirTy == i1Type || fromFirTy.isUnsignedInteger()) {
[flang] Use llvm.zext when converting from i1 -> iXX CodeGen used llvm.sext when converting fir.convert %0 : (i1) -> iXX where iXX is any integer. This leads to wrong values when the initial i1 is equal to 1. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D145984
2023-03-14 06:31:27 +01:00
rewriter.replaceOpWithNewOp<mlir::LLVM::ZExtOp>(convert, toTy, op0);
return mlir::success();
}
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
rewriter.replaceOpWithNewOp<mlir::LLVM::SExtOp>(convert, toTy, op0);
return mlir::success();
}
// Integer to floating point conversion.
if (isFloatingPointTy(toTy)) {
[flang] Add UNSIGNED (#113504) Implement the UNSIGNED extension type and operations under control of a language feature flag (-funsigned). This is nearly identical to the UNSIGNED feature that has been available in Sun Fortran for years, and now implemented in GNU Fortran for gfortran 15, and proposed for ISO standardization in J3/24-116.txt. See the new documentation for details; but in short, this is C's unsigned type, with guaranteed modular arithmetic for +, -, and *, and the related transformational intrinsic functions SUM & al.
2024-12-18 07:02:37 -08:00
if (fromTy.isUnsignedInteger())
rewriter.replaceOpWithNewOp<mlir::LLVM::UIToFPOp>(convert, toTy, op0);
else
rewriter.replaceOpWithNewOp<mlir::LLVM::SIToFPOp>(convert, toTy, op0);
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
return mlir::success();
}
// Integer to pointer conversion.
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (mlir::isa<mlir::LLVM::LLVMPointerType>(toTy)) {
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
rewriter.replaceOpWithNewOp<mlir::LLVM::IntToPtrOp>(convert, toTy, op0);
return mlir::success();
}
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
} else if (mlir::isa<mlir::LLVM::LLVMPointerType>(fromTy)) {
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
// Pointer to integer conversion.
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (mlir::isa<mlir::IntegerType>(toTy)) {
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
rewriter.replaceOpWithNewOp<mlir::LLVM::PtrToIntOp>(convert, toTy, op0);
return mlir::success();
}
// Pointer to pointer conversion.
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (mlir::isa<mlir::LLVM::LLVMPointerType>(toTy)) {
[fir] Add fir.convert op conversion from FIR to LLVM IR Add conversion pattern for the `fir.convert` operation. This patch is part of the upstreaming effort from fir-dev branch. This patch was previously landed with a truncated version that was failing the windows buildbot. Reviewed By: rovka, awarzynski Differential Revision: https://reviews.llvm.org/D113469 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 15:37:49 +01:00
rewriter.replaceOpWithNewOp<mlir::LLVM::BitcastOp>(convert, toTy, op0);
return mlir::success();
}
}
return emitError(loc) << "cannot convert " << fromTy << " to " << toTy;
}
};
[flang][nfc] replace fir.dispatch_table with more generic fir.type_info (#68309) The goal is to progressively propagate all the derived type info that is currently in the runtime type info globals into a FIR operation that can be easily queried and used by FIR/HLFIR passes. When this will be complete, the last step will be to stop generating the runtime info global in lowering, but to do that later in or just before codegen to keep the FIR files readable (on the added type-info.f90 tests, the lowered runtime info globals takes a whooping 2.6 millions characters on 1600 lines of the FIR textual output. The fir.type_info that contains all the info required to generate those globals for such "trivial" types takes 1721 characters on 9 lines). So far this patch simply starts by replacing the fir.dispatch_table operation by the fir.type_info operation and to add the noinit/ nofinal/nodestroy flags to it. These flags will soon be used in HLFIR to better rewrite hlfir.assign with derived types.
2023-10-06 09:29:57 +02:00
/// `fir.type_info` operation has no specific CodeGen. The operation is
/// only used to carry information during FIR to FIR passes. It may be used
/// in the future to generate the runtime type info data structures instead
/// of generating them in lowering.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct TypeInfoOpConversion : public fir::FIROpConversion<fir::TypeInfoOp> {
[fir] Add placeholder conversion pattern for disptach operations `fir.dispatch`, `fir.dispatch_table` and `fir.dt_entry` are operations for type-bound procedures. This patch just adds placeholder conversion pattern that currently fails since F2003 is not implemented yet. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113662
2021-11-11 13:58:39 +01:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[flang][nfc] replace fir.dispatch_table with more generic fir.type_info (#68309) The goal is to progressively propagate all the derived type info that is currently in the runtime type info globals into a FIR operation that can be easily queried and used by FIR/HLFIR passes. When this will be complete, the last step will be to stop generating the runtime info global in lowering, but to do that later in or just before codegen to keep the FIR files readable (on the added type-info.f90 tests, the lowered runtime info globals takes a whooping 2.6 millions characters on 1600 lines of the FIR textual output. The fir.type_info that contains all the info required to generate those globals for such "trivial" types takes 1721 characters on 9 lines). So far this patch simply starts by replacing the fir.dispatch_table operation by the fir.type_info operation and to add the noinit/ nofinal/nodestroy flags to it. These flags will soon be used in HLFIR to better rewrite hlfir.assign with derived types.
2023-10-06 09:29:57 +02:00
matchAndRewrite(fir::TypeInfoOp op, OpAdaptor,
[fir] Add placeholder conversion pattern for disptach operations `fir.dispatch`, `fir.dispatch_table` and `fir.dt_entry` are operations for type-bound procedures. This patch just adds placeholder conversion pattern that currently fails since F2003 is not implemented yet. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113662
2021-11-11 13:58:39 +01:00
mlir::ConversionPatternRewriter &rewriter) const override {
[flang] Create fir.dispatch_table and fir.dt_entry operations Create the fir.dispatch_table operation based on semantics information. The fir.dispatch_table will be used for static devirtualization as well as for fir.select_type conversion. Depends on D138129 Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D138131
2022-11-17 10:53:13 +01:00
rewriter.eraseOp(op);
return mlir::success();
[fir] Add placeholder conversion pattern for disptach operations `fir.dispatch`, `fir.dispatch_table` and `fir.dt_entry` are operations for type-bound procedures. This patch just adds placeholder conversion pattern that currently fails since F2003 is not implemented yet. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113662
2021-11-11 13:58:39 +01:00
}
};
[flang] Create fir.dispatch_table and fir.dt_entry operations Create the fir.dispatch_table operation based on semantics information. The fir.dispatch_table will be used for static devirtualization as well as for fir.select_type conversion. Depends on D138129 Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D138131
2022-11-17 10:53:13 +01:00
/// `fir.dt_entry` operation has no specific CodeGen. The operation is only used
/// to carry information during FIR to FIR passes.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct DTEntryOpConversion : public fir::FIROpConversion<fir::DTEntryOp> {
[fir] Add placeholder conversion pattern for disptach operations `fir.dispatch`, `fir.dispatch_table` and `fir.dt_entry` are operations for type-bound procedures. This patch just adds placeholder conversion pattern that currently fails since F2003 is not implemented yet. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113662
2021-11-11 13:58:39 +01:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[flang] Create fir.dispatch_table and fir.dt_entry operations Create the fir.dispatch_table operation based on semantics information. The fir.dispatch_table will be used for static devirtualization as well as for fir.select_type conversion. Depends on D138129 Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D138131
2022-11-17 10:53:13 +01:00
matchAndRewrite(fir::DTEntryOp op, OpAdaptor,
[fir] Add placeholder conversion pattern for disptach operations `fir.dispatch`, `fir.dispatch_table` and `fir.dt_entry` are operations for type-bound procedures. This patch just adds placeholder conversion pattern that currently fails since F2003 is not implemented yet. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113662
2021-11-11 13:58:39 +01:00
mlir::ConversionPatternRewriter &rewriter) const override {
[flang] Create fir.dispatch_table and fir.dt_entry operations Create the fir.dispatch_table operation based on semantics information. The fir.dispatch_table will be used for static devirtualization as well as for fir.select_type conversion. Depends on D138129 Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D138131
2022-11-17 10:53:13 +01:00
rewriter.eraseOp(op);
return mlir::success();
[fir] Add placeholder conversion pattern for disptach operations `fir.dispatch`, `fir.dispatch_table` and `fir.dt_entry` are operations for type-bound procedures. This patch just adds placeholder conversion pattern that currently fails since F2003 is not implemented yet. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113662
2021-11-11 13:58:39 +01:00
}
};
[fir] Add fir.global_len conversion placeholder As for D113662, this patch just add a place holder for the fir.global_len operation conversion. This operation is part of F20xx and is not implemented yet. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113887
2021-11-15 16:47:04 +01:00
/// Lower `fir.global_len` operation.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct GlobalLenOpConversion : public fir::FIROpConversion<fir::GlobalLenOp> {
[fir] Add fir.global_len conversion placeholder As for D113662, this patch just add a place holder for the fir.global_len operation conversion. This operation is part of F20xx and is not implemented yet. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113887
2021-11-15 16:47:04 +01:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[fir] Add fir.global_len conversion placeholder As for D113662, this patch just add a place holder for the fir.global_len operation conversion. This operation is part of F20xx and is not implemented yet. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113887
2021-11-15 16:47:04 +01:00
matchAndRewrite(fir::GlobalLenOp globalLen, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
[Flang] Replace notifyMatchFailure with TODO hard failures For unimplemented patterns we revert to using TODO hard failures instead of notifyMatchFailure. For fir.select_type revert to using mlir::emiterror. For the fir.embox TODO on a type with len params we cannot add a test since the type cannot be converted to llvm. Adding negative tests using not and checking for the error message. TODO exits with an error in a build without assertion but aborts in a build with assertions. Abort requires using not with the --crash option. The two different usages of not is handled by using a custom command %not_todo_cmd which is converted to not or not --crash depending on the presence or absence of assertions. Using llvm-config to check the presence of assertions. Reviewed By: clementval, awarzynski Differential Revision: https://reviews.llvm.org/D114371
2021-12-01 22:12:12 +00:00
TODO(globalLen.getLoc(), "fir.global_len codegen");
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::failure();
[fir] Add fir.global_len conversion placeholder As for D113662, this patch just add a place holder for the fir.global_len operation conversion. This operation is part of F20xx and is not implemented yet. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D113887
2021-11-15 16:47:04 +01:00
}
};
[fir] Set !fir.len_param_index conversion to unimplemented This patch is part of the upstreaming effort from fir-dev. The conversion of len_param_index in fir-dev is incomplete, so for now we're marking this as unimplemented until we can settle on a design for the runtime support of LEN parameters. Differential Revision: https://reviews.llvm.org/D114241 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-18 12:40:48 +00:00
/// Lower fir.len_param_index
struct LenParamIndexOpConversion
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
: public fir::FIROpConversion<fir::LenParamIndexOp> {
[fir] Set !fir.len_param_index conversion to unimplemented This patch is part of the upstreaming effort from fir-dev. The conversion of len_param_index in fir-dev is incomplete, so for now we're marking this as unimplemented until we can settle on a design for the runtime support of LEN parameters. Differential Revision: https://reviews.llvm.org/D114241 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-18 12:40:48 +00:00
using FIROpConversion::FIROpConversion;
// FIXME: this should be specialized by the runtime target
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[fir] Set !fir.len_param_index conversion to unimplemented This patch is part of the upstreaming effort from fir-dev. The conversion of len_param_index in fir-dev is incomplete, so for now we're marking this as unimplemented until we can settle on a design for the runtime support of LEN parameters. Differential Revision: https://reviews.llvm.org/D114241 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-18 12:40:48 +00:00
matchAndRewrite(fir::LenParamIndexOp lenp, OpAdaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
[Flang] Replace notifyMatchFailure with TODO hard failures For unimplemented patterns we revert to using TODO hard failures instead of notifyMatchFailure. For fir.select_type revert to using mlir::emiterror. For the fir.embox TODO on a type with len params we cannot add a test since the type cannot be converted to llvm. Adding negative tests using not and checking for the error message. TODO exits with an error in a build without assertion but aborts in a build with assertions. Abort requires using not with the --crash option. The two different usages of not is handled by using a custom command %not_todo_cmd which is converted to not or not --crash depending on the presence or absence of assertions. Using llvm-config to check the presence of assertions. Reviewed By: clementval, awarzynski Differential Revision: https://reviews.llvm.org/D114371
2021-12-01 22:12:12 +00:00
TODO(lenp.getLoc(), "fir.len_param_index codegen");
[fir] Set !fir.len_param_index conversion to unimplemented This patch is part of the upstreaming effort from fir-dev. The conversion of len_param_index in fir-dev is incomplete, so for now we're marking this as unimplemented until we can settle on a design for the runtime support of LEN parameters. Differential Revision: https://reviews.llvm.org/D114241 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-18 12:40:48 +00:00
}
};
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// Convert `!fir.emboxchar<!fir.char<KIND, ?>, #n>` into a sequence of
/// instructions that generate `!llvm.struct<(ptr<ik>, i64)>`. The 1st element
/// in this struct is a pointer. Its type is determined from `KIND`. The 2nd
/// element is the length of the character buffer (`#n`).
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct EmboxCharOpConversion : public fir::FIROpConversion<fir::EmboxCharOp> {
[fir] Add fir.gentypedesc conversion Add conversion pattern for the GenTypeDescOp. Convert to a global constant with an addressof. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113766 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-16 14:37:05 +01:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::EmboxCharOp emboxChar, OpAdaptor adaptor,
[fir] Add fir.gentypedesc conversion Add conversion pattern for the GenTypeDescOp. Convert to a global constant with an addressof. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113766 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-16 14:37:05 +01:00
mlir::ConversionPatternRewriter &rewriter) const override {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::ValueRange operands = adaptor.getOperands();
mlir::Value charBuffer = operands[0];
mlir::Value charBufferLen = operands[1];
mlir::Location loc = emboxChar.getLoc();
mlir::Type llvmStructTy = convertType(emboxChar.getType());
auto llvmStruct = rewriter.create<mlir::LLVM::UndefOp>(loc, llvmStructTy);
mlir::Type lenTy =
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
mlir::cast<mlir::LLVM::LLVMStructType>(llvmStructTy).getBody()[1];
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::Value lenAfterCast = integerCast(loc, rewriter, lenTy, charBufferLen);
[flang] fir.emboxchar codegen with static length fir.char types The verifier of fir.emboxchar accepts `fir.char<kind, constant>` types, but its codegen failed because of a missing cast. It is convenient and safe to not require making the cast in FIR, so add it in codegen. Differential Revision: https://reviews.llvm.org/D139514
2022-12-07 11:59:01 +01:00
mlir::Type addrTy =
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
mlir::cast<mlir::LLVM::LLVMStructType>(llvmStructTy).getBody()[0];
[flang] fir.emboxchar codegen with static length fir.char types The verifier of fir.emboxchar accepts `fir.char<kind, constant>` types, but its codegen failed because of a missing cast. It is convenient and safe to not require making the cast in FIR, so add it in codegen. Differential Revision: https://reviews.llvm.org/D139514
2022-12-07 11:59:01 +01:00
if (addrTy != charBuffer.getType())
charBuffer =
rewriter.create<mlir::LLVM::BitcastOp>(loc, addrTy, charBuffer);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
auto insertBufferOp = rewriter.create<mlir::LLVM::InsertValueOp>(
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
loc, llvmStruct, charBuffer, 0);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
rewriter.replaceOpWithNewOp<mlir::LLVM::InsertValueOp>(
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
emboxChar, insertBufferOp, lenAfterCast, 1);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[fir] Add fir.gentypedesc conversion Add conversion pattern for the GenTypeDescOp. Convert to a global constant with an addressof. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113766 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-16 14:37:05 +01:00
}
};
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
} // namespace
[flang][cuda] Support malloc and free conversion in gpu module (#116112)
2024-11-13 17:09:38 -08:00
template <typename ModuleOp>
[flang] Allow user to define free via BIND(C) (#78428) A user defining and using free/malloc via BIND(C) would previously cause flang to crash when generating LLVM IR with error "redefinition of symbol named 'free'". This was caused by flang codegen not expecting to find a mlir::func::FuncOp definition of these function and emitting a new mlir::LLVM::FuncOp that later conflicted when translating the mlir::func::FuncOp.
2024-01-18 09:37:44 +01:00
static mlir::SymbolRefAttr
[flang][cuda] Support malloc and free conversion in gpu module (#116112)
2024-11-13 17:09:38 -08:00
getMallocInModule(ModuleOp mod, fir::AllocMemOp op,
Reland [flang] In AllocMemOp lowering, convert types for calling malloc on 32-bit (#130386) Previous PR: https://github.com/llvm/llvm-project/pull/129308 Changes: * The alloc-32.fir test is now marked as requiring the X86 target. * Drive-by fixes uncovered when fixing tests involving malloc
2025-03-11 02:01:57 +00:00
mlir::ConversionPatternRewriter &rewriter,
mlir::Type indexType) {
[flang] Allow user to define free via BIND(C) (#78428) A user defining and using free/malloc via BIND(C) would previously cause flang to crash when generating LLVM IR with error "redefinition of symbol named 'free'". This was caused by flang codegen not expecting to find a mlir::func::FuncOp definition of these function and emitting a new mlir::LLVM::FuncOp that later conflicted when translating the mlir::func::FuncOp.
2024-01-18 09:37:44 +01:00
static constexpr char mallocName[] = "malloc";
[flang][cuda] Support malloc and free conversion in gpu module (#116112)
2024-11-13 17:09:38 -08:00
if (auto mallocFunc =
mod.template lookupSymbol<mlir::LLVM::LLVMFuncOp>(mallocName))
[flang] Allow user to define free via BIND(C) (#78428) A user defining and using free/malloc via BIND(C) would previously cause flang to crash when generating LLVM IR with error "redefinition of symbol named 'free'". This was caused by flang codegen not expecting to find a mlir::func::FuncOp definition of these function and emitting a new mlir::LLVM::FuncOp that later conflicted when translating the mlir::func::FuncOp.
2024-01-18 09:37:44 +01:00
return mlir::SymbolRefAttr::get(mallocFunc);
[flang][cuda] Support malloc and free conversion in gpu module (#116112)
2024-11-13 17:09:38 -08:00
if (auto userMalloc =
mod.template lookupSymbol<mlir::func::FuncOp>(mallocName))
[flang] Allow user to define free via BIND(C) (#78428) A user defining and using free/malloc via BIND(C) would previously cause flang to crash when generating LLVM IR with error "redefinition of symbol named 'free'". This was caused by flang codegen not expecting to find a mlir::func::FuncOp definition of these function and emitting a new mlir::LLVM::FuncOp that later conflicted when translating the mlir::func::FuncOp.
2024-01-18 09:37:44 +01:00
return mlir::SymbolRefAttr::get(userMalloc);
[flang][cuda] Support malloc and free conversion in gpu module (#116112)
2024-11-13 17:09:38 -08:00
mlir::OpBuilder moduleBuilder(mod.getBodyRegion());
[flang] Allow user to define free via BIND(C) (#78428) A user defining and using free/malloc via BIND(C) would previously cause flang to crash when generating LLVM IR with error "redefinition of symbol named 'free'". This was caused by flang codegen not expecting to find a mlir::func::FuncOp definition of these function and emitting a new mlir::LLVM::FuncOp that later conflicted when translating the mlir::func::FuncOp.
2024-01-18 09:37:44 +01:00
auto mallocDecl = moduleBuilder.create<mlir::LLVM::LLVMFuncOp>(
op.getLoc(), mallocName,
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::LLVM::LLVMFunctionType::get(getLlvmPtrType(op.getContext()),
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
indexType,
/*isVarArg=*/false));
[flang] Allow user to define free via BIND(C) (#78428) A user defining and using free/malloc via BIND(C) would previously cause flang to crash when generating LLVM IR with error "redefinition of symbol named 'free'". This was caused by flang codegen not expecting to find a mlir::func::FuncOp definition of these function and emitting a new mlir::LLVM::FuncOp that later conflicted when translating the mlir::func::FuncOp.
2024-01-18 09:37:44 +01:00
return mlir::SymbolRefAttr::get(mallocDecl);
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
}
[flang][cuda] Support malloc and free conversion in gpu module (#116112)
2024-11-13 17:09:38 -08:00
/// Return the LLVMFuncOp corresponding to the standard malloc call.
Reland [flang] In AllocMemOp lowering, convert types for calling malloc on 32-bit (#130386) Previous PR: https://github.com/llvm/llvm-project/pull/129308 Changes: * The alloc-32.fir test is now marked as requiring the X86 target. * Drive-by fixes uncovered when fixing tests involving malloc
2025-03-11 02:01:57 +00:00
static mlir::SymbolRefAttr getMalloc(fir::AllocMemOp op,
mlir::ConversionPatternRewriter &rewriter,
mlir::Type indexType) {
[flang][cuda] Support malloc and free conversion in gpu module (#116112)
2024-11-13 17:09:38 -08:00
if (auto mod = op->getParentOfType<mlir::gpu::GPUModuleOp>())
Reland [flang] In AllocMemOp lowering, convert types for calling malloc on 32-bit (#130386) Previous PR: https://github.com/llvm/llvm-project/pull/129308 Changes: * The alloc-32.fir test is now marked as requiring the X86 target. * Drive-by fixes uncovered when fixing tests involving malloc
2025-03-11 02:01:57 +00:00
return getMallocInModule(mod, op, rewriter, indexType);
[flang][cuda] Support malloc and free conversion in gpu module (#116112)
2024-11-13 17:09:38 -08:00
auto mod = op->getParentOfType<mlir::ModuleOp>();
Reland [flang] In AllocMemOp lowering, convert types for calling malloc on 32-bit (#130386) Previous PR: https://github.com/llvm/llvm-project/pull/129308 Changes: * The alloc-32.fir test is now marked as requiring the X86 target. * Drive-by fixes uncovered when fixing tests involving malloc
2025-03-11 02:01:57 +00:00
return getMallocInModule(mod, op, rewriter, indexType);
[flang][cuda] Support malloc and free conversion in gpu module (#116112)
2024-11-13 17:09:38 -08:00
}
[flang] Compute type allocation size based on the actual target representation. This change makes sure that we compute the element size and the byte stride based on the target representation of the element type. For example, when REAL*10 is mapped to x86_fp80 each element occupies 16 bytes rather than 10 because of the padding. Note that the size computation method used here actually returns the distance between two adjacent element of the *same* type in memory (which is equivalent to llvm::DataLayout::getTypeAllocSize()). It does not return the number of bytes that may be overwritten by storing a value of the specified type (e.g. what can be computed via llvm::DataLayout::getTypeStoreSize(), but not available in mlir::DataLayout). Differential Revision: https://reviews.llvm.org/D133508
2022-09-08 10:13:45 -07:00
/// Helper function for generating the LLVM IR that computes the distance
/// in bytes between adjacent elements pointed to by a pointer
/// of type \p ptrTy. The result is returned as a value of \p idxTy integer
/// type.
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
static mlir::Value
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
computeElementDistance(mlir::Location loc, mlir::Type llvmObjectType,
mlir::Type idxTy,
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
mlir::ConversionPatternRewriter &rewriter) {
[flang] Compute type allocation size based on the actual target representation. This change makes sure that we compute the element size and the byte stride based on the target representation of the element type. For example, when REAL*10 is mapped to x86_fp80 each element occupies 16 bytes rather than 10 because of the padding. Note that the size computation method used here actually returns the distance between two adjacent element of the *same* type in memory (which is equivalent to llvm::DataLayout::getTypeAllocSize()). It does not return the number of bytes that may be overwritten by storing a value of the specified type (e.g. what can be computed via llvm::DataLayout::getTypeStoreSize(), but not available in mlir::DataLayout). Differential Revision: https://reviews.llvm.org/D133508
2022-09-08 10:13:45 -07:00
// Note that we cannot use something like
// mlir::LLVM::getPrimitiveTypeSizeInBits() for the element type here. For
// example, it returns 10 bytes for mlir::Float80Type for targets where it
// occupies 16 bytes. Proper solution is probably to use
// mlir::DataLayout::getTypeABIAlignment(), but DataLayout is not being set
// yet (see llvm-project#57230). For the time being use the '(intptr_t)((type
// *)0 + 1)' trick for all types. The generated instructions are optimized
// into constant by the first pass of InstCombine, so it should not be a
// performance issue.
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
auto llvmPtrTy = ::getLlvmPtrType(llvmObjectType.getContext());
auto nullPtr = rewriter.create<mlir::LLVM::ZeroOp>(loc, llvmPtrTy);
[mlir][flang] Make use of the new `GEPArg` builder of GEP Op to simplify code This is the follow up on https://reviews.llvm.org/D130730 which goes through upstream code and removes creating constant values in favour of using the constant indices in GEP directly. This leads to less and more readable code and more compact IR as well. Differential Revision: https://reviews.llvm.org/D130731
2022-07-29 01:00:22 +02:00
auto gep = rewriter.create<mlir::LLVM::GEPOp>(
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
loc, llvmPtrTy, llvmObjectType, nullPtr,
llvm::ArrayRef<mlir::LLVM::GEPArg>{1});
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
return rewriter.create<mlir::LLVM::PtrToIntOp>(loc, idxTy, gep);
}
[flang] Compute type allocation size based on the actual target representation. This change makes sure that we compute the element size and the byte stride based on the target representation of the element type. For example, when REAL*10 is mapped to x86_fp80 each element occupies 16 bytes rather than 10 because of the padding. Note that the size computation method used here actually returns the distance between two adjacent element of the *same* type in memory (which is equivalent to llvm::DataLayout::getTypeAllocSize()). It does not return the number of bytes that may be overwritten by storing a value of the specified type (e.g. what can be computed via llvm::DataLayout::getTypeStoreSize(), but not available in mlir::DataLayout). Differential Revision: https://reviews.llvm.org/D133508
2022-09-08 10:13:45 -07:00
/// Return value of the stride in bytes between adjacent elements
/// of LLVM type \p llTy. The result is returned as a value of
/// \p idxTy integer type.
static mlir::Value
genTypeStrideInBytes(mlir::Location loc, mlir::Type idxTy,
mlir::ConversionPatternRewriter &rewriter,
mlir::Type llTy) {
// Create a pointer type and use computeElementDistance().
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
return computeElementDistance(loc, llTy, idxTy, rewriter);
[flang] Compute type allocation size based on the actual target representation. This change makes sure that we compute the element size and the byte stride based on the target representation of the element type. For example, when REAL*10 is mapped to x86_fp80 each element occupies 16 bytes rather than 10 because of the padding. Note that the size computation method used here actually returns the distance between two adjacent element of the *same* type in memory (which is equivalent to llvm::DataLayout::getTypeAllocSize()). It does not return the number of bytes that may be overwritten by storing a value of the specified type (e.g. what can be computed via llvm::DataLayout::getTypeStoreSize(), but not available in mlir::DataLayout). Differential Revision: https://reviews.llvm.org/D133508
2022-09-08 10:13:45 -07:00
}
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
namespace {
/// Lower a `fir.allocmem` instruction into `llvm.call @malloc`
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct AllocMemOpConversion : public fir::FIROpConversion<fir::AllocMemOp> {
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
matchAndRewrite(fir::AllocMemOp heap, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
[flang][NFC] Fix some formatting Fix some mismatch in format used in the file and reduce the diff with fir-dev to be able to finish the upstreaming on this file. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: PeteSteinfeld, kiranchandramohan Differential Revision: https://reviews.llvm.org/D127849
2022-06-15 16:48:46 +02:00
mlir::Type heapTy = heap.getType();
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
mlir::Location loc = heap.getLoc();
auto ity = lowerTy().indexType();
[flang][NFC] Fix some formatting Fix some mismatch in format used in the file and reduce the diff with fir-dev to be able to finish the upstreaming on this file. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: PeteSteinfeld, kiranchandramohan Differential Revision: https://reviews.llvm.org/D127849
2022-06-15 16:48:46 +02:00
mlir::Type dataTy = fir::unwrapRefType(heapTy);
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::Type llvmObjectTy = convertObjectType(dataTy);
[flang] Upstream fix to allocmem codegen to deal with missing dimensions for sequence of character types. Upstream type test. Upstream test. Fix tests. Do not run on windows, as that is not an implemented target. Differential Revision: https://reviews.llvm.org/D119551
2022-02-10 18:40:13 -08:00
if (fir::isRecordWithTypeParameters(fir::unwrapSequenceType(dataTy)))
TODO(loc, "fir.allocmem codegen of derived type with length parameters");
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::Value size = genTypeSizeInBytes(loc, ity, rewriter, llvmObjectTy);
[flang] Fix AllocaOp/AllocMemOp type conversion For arrays without a constant interior or arrays of character with dynamic length arrays, the data types are converted to a pointer to the element type, so the scale size of the constant extents needs to be counted. The previous AllocaOp conversion does not consider the arrays of character with dynamic length arrays, and the previous AllocMemOp conversion does not consider arrays without a constant interior. This fixes them and refactors the code so that it can be shared. Also add the test cases. Reviewed By: Jean Perier Differential Revision: https://reviews.llvm.org/D124766
2022-05-06 22:10:13 +08:00
if (auto scaleSize = genAllocationScaleSize(heap, ity, rewriter))
size = rewriter.create<mlir::LLVM::MulOp>(loc, ity, size, scaleSize);
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
for (mlir::Value opnd : adaptor.getOperands())
size = rewriter.create<mlir::LLVM::MulOp>(
loc, ity, size, integerCast(loc, rewriter, ity, opnd));
Reland [flang] In AllocMemOp lowering, convert types for calling malloc on 32-bit (#130386) Previous PR: https://github.com/llvm/llvm-project/pull/129308 Changes: * The alloc-32.fir test is now marked as requiring the X86 target. * Drive-by fixes uncovered when fixing tests involving malloc
2025-03-11 02:01:57 +00:00
auto mallocTyWidth = lowerTy().getIndexTypeBitwidth();
auto mallocTy =
mlir::IntegerType::get(rewriter.getContext(), mallocTyWidth);
if (mallocTyWidth != ity.getIntOrFloatBitWidth())
size = integerCast(loc, rewriter, mallocTy, size);
heap->setAttr("callee", getMalloc(heap, rewriter, mallocTy));
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
rewriter.replaceOpWithNewOp<mlir::LLVM::CallOp>(
[mlir][LLVM] Add operand bundle support (#108933) This PR adds LLVM [operand bundle](https://llvm.org/docs/LangRef.html#operand-bundles) support to MLIR LLVM dialect. It affects these 3 operations related to making function calls: `llvm.call`, `llvm.invoke`, and `llvm.call_intrinsic`. This PR adds two new parameters to each of the 3 operations. The first parameter is a variadic operand `op_bundle_operands` that contains the SSA values for operand bundles. The second parameter is a property `op_bundle_tags` which holds an array of strings that represent the tags of each operand bundle.
2024-09-26 13:59:37 +08:00
heap, ::getLlvmPtrType(heap.getContext()), size,
addLLVMOpBundleAttrs(rewriter, heap->getAttrs(), 1));
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
}
[flang] Compute type allocation size based on the actual target representation. This change makes sure that we compute the element size and the byte stride based on the target representation of the element type. For example, when REAL*10 is mapped to x86_fp80 each element occupies 16 bytes rather than 10 because of the padding. Note that the size computation method used here actually returns the distance between two adjacent element of the *same* type in memory (which is equivalent to llvm::DataLayout::getTypeAllocSize()). It does not return the number of bytes that may be overwritten by storing a value of the specified type (e.g. what can be computed via llvm::DataLayout::getTypeStoreSize(), but not available in mlir::DataLayout). Differential Revision: https://reviews.llvm.org/D133508
2022-09-08 10:13:45 -07:00
/// Compute the allocation size in bytes of the element type of
/// \p llTy pointer type. The result is returned as a value of \p idxTy
/// integer type.
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
mlir::Value genTypeSizeInBytes(mlir::Location loc, mlir::Type idxTy,
mlir::ConversionPatternRewriter &rewriter,
mlir::Type llTy) const {
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
return computeElementDistance(loc, llTy, idxTy, rewriter);
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
}
};
} // namespace
/// Return the LLVMFuncOp corresponding to the standard free call.
[flang][cuda] Support malloc and free conversion in gpu module (#116112)
2024-11-13 17:09:38 -08:00
template <typename ModuleOp>
static mlir::SymbolRefAttr
getFreeInModule(ModuleOp mod, fir::FreeMemOp op,
mlir::ConversionPatternRewriter &rewriter) {
[flang] Allow user to define free via BIND(C) (#78428) A user defining and using free/malloc via BIND(C) would previously cause flang to crash when generating LLVM IR with error "redefinition of symbol named 'free'". This was caused by flang codegen not expecting to find a mlir::func::FuncOp definition of these function and emitting a new mlir::LLVM::FuncOp that later conflicted when translating the mlir::func::FuncOp.
2024-01-18 09:37:44 +01:00
static constexpr char freeName[] = "free";
// Check if free already defined in the module.
[flang][cuda] Support malloc and free conversion in gpu module (#116112)
2024-11-13 17:09:38 -08:00
if (auto freeFunc =
mod.template lookupSymbol<mlir::LLVM::LLVMFuncOp>(freeName))
[flang] Allow user to define free via BIND(C) (#78428) A user defining and using free/malloc via BIND(C) would previously cause flang to crash when generating LLVM IR with error "redefinition of symbol named 'free'". This was caused by flang codegen not expecting to find a mlir::func::FuncOp definition of these function and emitting a new mlir::LLVM::FuncOp that later conflicted when translating the mlir::func::FuncOp.
2024-01-18 09:37:44 +01:00
return mlir::SymbolRefAttr::get(freeFunc);
if (auto freeDefinedByUser =
[flang][cuda] Support malloc and free conversion in gpu module (#116112)
2024-11-13 17:09:38 -08:00
mod.template lookupSymbol<mlir::func::FuncOp>(freeName))
[flang] Allow user to define free via BIND(C) (#78428) A user defining and using free/malloc via BIND(C) would previously cause flang to crash when generating LLVM IR with error "redefinition of symbol named 'free'". This was caused by flang codegen not expecting to find a mlir::func::FuncOp definition of these function and emitting a new mlir::LLVM::FuncOp that later conflicted when translating the mlir::func::FuncOp.
2024-01-18 09:37:44 +01:00
return mlir::SymbolRefAttr::get(freeDefinedByUser);
// Create llvm declaration for free.
[flang][cuda] Support malloc and free conversion in gpu module (#116112)
2024-11-13 17:09:38 -08:00
mlir::OpBuilder moduleBuilder(mod.getBodyRegion());
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
auto voidType = mlir::LLVM::LLVMVoidType::get(op.getContext());
[flang] Allow user to define free via BIND(C) (#78428) A user defining and using free/malloc via BIND(C) would previously cause flang to crash when generating LLVM IR with error "redefinition of symbol named 'free'". This was caused by flang codegen not expecting to find a mlir::func::FuncOp definition of these function and emitting a new mlir::LLVM::FuncOp that later conflicted when translating the mlir::func::FuncOp.
2024-01-18 09:37:44 +01:00
auto freeDecl = moduleBuilder.create<mlir::LLVM::LLVMFuncOp>(
rewriter.getUnknownLoc(), freeName,
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
mlir::LLVM::LLVMFunctionType::get(voidType,
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
getLlvmPtrType(op.getContext()),
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
/*isVarArg=*/false));
[flang] Allow user to define free via BIND(C) (#78428) A user defining and using free/malloc via BIND(C) would previously cause flang to crash when generating LLVM IR with error "redefinition of symbol named 'free'". This was caused by flang codegen not expecting to find a mlir::func::FuncOp definition of these function and emitting a new mlir::LLVM::FuncOp that later conflicted when translating the mlir::func::FuncOp.
2024-01-18 09:37:44 +01:00
return mlir::SymbolRefAttr::get(freeDecl);
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
}
[flang][cuda] Support malloc and free conversion in gpu module (#116112)
2024-11-13 17:09:38 -08:00
static mlir::SymbolRefAttr getFree(fir::FreeMemOp op,
mlir::ConversionPatternRewriter &rewriter) {
if (auto mod = op->getParentOfType<mlir::gpu::GPUModuleOp>())
return getFreeInModule(mod, op, rewriter);
auto mod = op->getParentOfType<mlir::ModuleOp>();
return getFreeInModule(mod, op, rewriter);
}
[flang] Avoid opaque pointer issue with character array substring addressing When addressing a substring of a character array, codegen emits two GEPs: one for to compute the address of the base element, and a second one to address the first characters from that element. The first GEP still returns the LLVM array type (if the FIR array type could be translated to an array type. Therefore) so zero indexes must be added to the second GEP in this case to cover for the Fortran array dimensions before inserting the susbtring offset index. Surprisingly, the previous code worked ok when MLIR emits none opaque pointers. But with opaque pointers, the two GEPs are folded in an invalid GEP where the substring offset becomes an offset for the outer array dimension. Note that I tried to fix the issue by modifying the first GEP to return the element type, but this still gave bad results (here something might be wrong with opaque pointer in MLIR or LLVM). Differential Revision: https://reviews.llvm.org/D129079
2022-07-05 09:13:07 +02:00
static unsigned getDimension(mlir::LLVM::LLVMArrayType ty) {
unsigned result = 1;
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
for (auto eleTy =
mlir::dyn_cast<mlir::LLVM::LLVMArrayType>(ty.getElementType());
eleTy; eleTy = mlir::dyn_cast<mlir::LLVM::LLVMArrayType>(
eleTy.getElementType()))
[flang] Avoid opaque pointer issue with character array substring addressing When addressing a substring of a character array, codegen emits two GEPs: one for to compute the address of the base element, and a second one to address the first characters from that element. The first GEP still returns the LLVM array type (if the FIR array type could be translated to an array type. Therefore) so zero indexes must be added to the second GEP in this case to cover for the Fortran array dimensions before inserting the susbtring offset index. Surprisingly, the previous code worked ok when MLIR emits none opaque pointers. But with opaque pointers, the two GEPs are folded in an invalid GEP where the substring offset becomes an offset for the outer array dimension. Note that I tried to fix the issue by modifying the first GEP to return the element type, but this still gave bad results (here something might be wrong with opaque pointer in MLIR or LLVM). Differential Revision: https://reviews.llvm.org/D129079
2022-07-05 09:13:07 +02:00
++result;
return result;
}
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
namespace {
/// Lower a `fir.freemem` instruction into `llvm.call @free`
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct FreeMemOpConversion : public fir::FIROpConversion<fir::FreeMemOp> {
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
matchAndRewrite(fir::FreeMemOp freemem, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
mlir::Location loc = freemem.getLoc();
[flang] Allow user to define free via BIND(C) (#78428) A user defining and using free/malloc via BIND(C) would previously cause flang to crash when generating LLVM IR with error "redefinition of symbol named 'free'". This was caused by flang codegen not expecting to find a mlir::func::FuncOp definition of these function and emitting a new mlir::LLVM::FuncOp that later conflicted when translating the mlir::func::FuncOp.
2024-01-18 09:37:44 +01:00
freemem->setAttr("callee", getFree(freemem, rewriter));
[mlir][LLVM] Add operand bundle support (#108933) This PR adds LLVM [operand bundle](https://llvm.org/docs/LangRef.html#operand-bundles) support to MLIR LLVM dialect. It affects these 3 operations related to making function calls: `llvm.call`, `llvm.invoke`, and `llvm.call_intrinsic`. This PR adds two new parameters to each of the 3 operations. The first parameter is a variadic operand `op_bundle_operands` that contains the SSA values for operand bundles. The second parameter is a property `op_bundle_tags` which holds an array of strings that represent the tags of each operand bundle.
2024-09-26 13:59:37 +08:00
rewriter.create<mlir::LLVM::CallOp>(
loc, mlir::TypeRange{}, mlir::ValueRange{adaptor.getHeapref()},
addLLVMOpBundleAttrs(rewriter, freemem->getAttrs(), 1));
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
rewriter.eraseOp(freemem);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
Convert fir.allocmem and fir.freemem operations to calls to malloc and free, respectively This patch is part of the upstreaming effort from the fir-dev branch. Address review comments - move CHECK blocks to after the mlir code in the test file - fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace - fix a few nits - remove TODO in favor of notifyMatchFailure - removed unnecessary CHECK line from convert-to-llvm.fir - rebase on main - add TODO back in - get successfull test of TODO in AllocMemOp converion of derived type with LEN params - clearer comments and reduced use of auto - move defintion of computeDerivedTypeSize to fix build error Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz Differential Revision: https://reviews.llvm.org/D114104
2021-11-02 15:46:21 -06:00
}
};
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
} // namespace
[fir] Add fir.gentypedesc conversion Add conversion pattern for the GenTypeDescOp. Convert to a global constant with an addressof. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113766 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-16 14:37:05 +01:00
[flang] Fix codegen of subcomponents' indexing Identify multidimensional array indices in subcomponents and convert them from column-major to row-major ordering. This fixes codegen for fircg.ext_array_coor, fircg.ext_embox and, possibly, fircg.ext_rebox. Fixes https://github.com/llvm/llvm-project/issues/62038 Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D154214
2023-06-29 14:46:58 +00:00
// Convert subcomponent array indices from column-major to row-major ordering.
static llvm::SmallVector<mlir::Value>
convertSubcomponentIndices(mlir::Location loc, mlir::Type eleTy,
mlir::ValueRange indices,
mlir::Type *retTy = nullptr) {
llvm::SmallVector<mlir::Value> result;
llvm::SmallVector<mlir::Value> arrayIndices;
auto appendArrayIndices = [&] {
if (arrayIndices.empty())
return;
std::reverse(arrayIndices.begin(), arrayIndices.end());
result.append(arrayIndices.begin(), arrayIndices.end());
arrayIndices.clear();
};
for (mlir::Value index : indices) {
// Component indices can be field index to select a component, or array
// index, to select an element in an array component.
if (auto structTy = mlir::dyn_cast<mlir::LLVM::LLVMStructType>(eleTy)) {
std::int64_t cstIndex = getConstantIntValue(index);
assert(cstIndex < (int64_t)structTy.getBody().size() &&
"out-of-bounds struct field index");
eleTy = structTy.getBody()[cstIndex];
appendArrayIndices();
result.push_back(index);
} else if (auto arrayTy =
mlir::dyn_cast<mlir::LLVM::LLVMArrayType>(eleTy)) {
eleTy = arrayTy.getElementType();
arrayIndices.push_back(index);
} else
fir::emitFatalError(loc, "Unexpected subcomponent type");
}
appendArrayIndices();
if (retTy)
*retTy = eleTy;
return result;
}
[flang][cuda] Allocate descriptor in managed memory when emboxing device memory (#120485) When emboxing memory that comes from CUFMemAlloc, we need to allocate the descriptor in manage memory as it might be passed to a kernel.
2024-12-18 18:20:45 -08:00
static mlir::Value genSourceFile(mlir::Location loc, mlir::ModuleOp mod,
mlir::ConversionPatternRewriter &rewriter) {
auto ptrTy = mlir::LLVM::LLVMPointerType::get(rewriter.getContext());
if (auto flc = mlir::dyn_cast<mlir::FileLineColLoc>(loc)) {
auto fn = flc.getFilename().str() + '\0';
std::string globalName = fir::factory::uniqueCGIdent("cl", fn);
if (auto g = mod.lookupSymbol<fir::GlobalOp>(globalName)) {
return rewriter.create<mlir::LLVM::AddressOfOp>(loc, ptrTy, g.getName());
} else if (auto g = mod.lookupSymbol<mlir::LLVM::GlobalOp>(globalName)) {
return rewriter.create<mlir::LLVM::AddressOfOp>(loc, ptrTy, g.getName());
}
auto crtInsPt = rewriter.saveInsertionPoint();
rewriter.setInsertionPoint(mod.getBody(), mod.getBody()->end());
auto arrayTy = mlir::LLVM::LLVMArrayType::get(
mlir::IntegerType::get(rewriter.getContext(), 8), fn.size());
mlir::LLVM::GlobalOp globalOp = rewriter.create<mlir::LLVM::GlobalOp>(
loc, arrayTy, /*constant=*/true, mlir::LLVM::Linkage::Linkonce,
globalName, mlir::Attribute());
mlir::Region &region = globalOp.getInitializerRegion();
mlir::Block *block = rewriter.createBlock(&region);
rewriter.setInsertionPoint(block, block->begin());
mlir::Value constValue = rewriter.create<mlir::LLVM::ConstantOp>(
loc, arrayTy, rewriter.getStringAttr(fn));
rewriter.create<mlir::LLVM::ReturnOp>(loc, constValue);
rewriter.restoreInsertionPoint(crtInsPt);
return rewriter.create<mlir::LLVM::AddressOfOp>(loc, ptrTy,
globalOp.getName());
}
return rewriter.create<mlir::LLVM::ZeroOp>(loc, ptrTy);
}
static mlir::Value genSourceLine(mlir::Location loc,
mlir::ConversionPatternRewriter &rewriter) {
if (auto flc = mlir::dyn_cast<mlir::FileLineColLoc>(loc))
return rewriter.create<mlir::LLVM::ConstantOp>(loc, rewriter.getI32Type(),
flc.getLine());
return rewriter.create<mlir::LLVM::ConstantOp>(loc, rewriter.getI32Type(), 0);
}
static mlir::Value
genCUFAllocDescriptor(mlir::Location loc,
mlir::ConversionPatternRewriter &rewriter,
mlir::ModuleOp mod, fir::BaseBoxType boxTy,
const fir::LLVMTypeConverter &typeConverter) {
std::optional<mlir::DataLayout> dl =
[Flang][MLIR] Extend DataLayout utilities to have basic GPU Module support (#123149) As there is now certain areas where we now have the possibility of having either a ModuleOp or GPUModuleOp and both of these modules can have DataLayout's and we may require utilising the DataLayout utilities in these areas I've taken the liberty of trying to extend them for use with both. Those with more knowledge of how they wish the GPUModuleOp's to interact with their parent ModuleOp's DataLayout may have further alterations they wish to make in the future, but for the moment, it'll simply utilise the basic data layout construction which I believe combines parent and child datalayouts from the ModuleOp and GPUModuleOp. If there is no GPUModuleOp DataLayout it should default to the parent ModuleOp. It's worth noting there is some weirdness if you have two module operations defining builtin dialect DataLayout Entries, it appears the combinatorial functionality for DataLayouts doesn't support the merging of these. This behaviour is useful for areas like: https://github.com/llvm/llvm-project/pull/119585/files#diff-19fc4bcb38829d085e25d601d344bbd85bf7ef749ca359e348f4a7c750eae89dR1412 where we have a crossroads between the two different module operations.
2025-01-30 17:31:50 +01:00
fir::support::getOrSetMLIRDataLayout(mod, /*allowDefaultLayout=*/true);
[flang][cuda] Allocate descriptor in managed memory when emboxing device memory (#120485) When emboxing memory that comes from CUFMemAlloc, we need to allocate the descriptor in manage memory as it might be passed to a kernel.
2024-12-18 18:20:45 -08:00
if (!dl)
mlir::emitError(mod.getLoc(),
"module operation must carry a data layout attribute "
"to generate llvm IR from FIR");
mlir::Value sourceFile = genSourceFile(loc, mod, rewriter);
mlir::Value sourceLine = genSourceLine(loc, rewriter);
mlir::MLIRContext *ctx = mod.getContext();
mlir::LLVM::LLVMPointerType llvmPointerType =
mlir::LLVM::LLVMPointerType::get(ctx);
mlir::Type llvmInt32Type = mlir::IntegerType::get(ctx, 32);
mlir::Type llvmIntPtrType =
mlir::IntegerType::get(ctx, typeConverter.getPointerBitwidth(0));
auto fctTy = mlir::LLVM::LLVMFunctionType::get(
llvmPointerType, {llvmIntPtrType, llvmPointerType, llvmInt32Type});
auto llvmFunc = mod.lookupSymbol<mlir::LLVM::LLVMFuncOp>(
[flang][cuda][NFC] Fix typo in CUFAllocDescriptor (#120797) Missing `r` in the function name.
2024-12-20 13:57:47 -08:00
RTNAME_STRING(CUFAllocDescriptor));
[flang][cuda] Allocate descriptor in managed memory when emboxing device memory (#120485) When emboxing memory that comes from CUFMemAlloc, we need to allocate the descriptor in manage memory as it might be passed to a kernel.
2024-12-18 18:20:45 -08:00
auto funcFunc =
[flang][cuda][NFC] Fix typo in CUFAllocDescriptor (#120797) Missing `r` in the function name.
2024-12-20 13:57:47 -08:00
mod.lookupSymbol<mlir::func::FuncOp>(RTNAME_STRING(CUFAllocDescriptor));
[flang][cuda] Allocate descriptor in managed memory when emboxing device memory (#120485) When emboxing memory that comes from CUFMemAlloc, we need to allocate the descriptor in manage memory as it might be passed to a kernel.
2024-12-18 18:20:45 -08:00
if (!llvmFunc && !funcFunc)
mlir::OpBuilder::atBlockEnd(mod.getBody())
[flang][cuda][NFC] Fix typo in CUFAllocDescriptor (#120797) Missing `r` in the function name.
2024-12-20 13:57:47 -08:00
.create<mlir::LLVM::LLVMFuncOp>(loc, RTNAME_STRING(CUFAllocDescriptor),
[flang][cuda] Allocate descriptor in managed memory when emboxing device memory (#120485) When emboxing memory that comes from CUFMemAlloc, we need to allocate the descriptor in manage memory as it might be passed to a kernel.
2024-12-18 18:20:45 -08:00
fctTy);
mlir::Type structTy = typeConverter.convertBoxTypeAsStruct(boxTy);
std::size_t boxSize = dl->getTypeSizeInBits(structTy) / 8;
mlir::Value sizeInBytes =
genConstantIndex(loc, llvmIntPtrType, rewriter, boxSize);
llvm::SmallVector args = {sizeInBytes, sourceFile, sourceLine};
return rewriter
[flang][cuda][NFC] Fix typo in CUFAllocDescriptor (#120797) Missing `r` in the function name.
2024-12-20 13:57:47 -08:00
.create<mlir::LLVM::CallOp>(loc, fctTy, RTNAME_STRING(CUFAllocDescriptor),
[flang][cuda] Allocate descriptor in managed memory when emboxing device memory (#120485) When emboxing memory that comes from CUFMemAlloc, we need to allocate the descriptor in manage memory as it might be passed to a kernel.
2024-12-18 18:20:45 -08:00
args)
.getResult();
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// Common base class for embox to descriptor conversion.
template <typename OP>
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct EmboxCommonConversion : public fir::FIROpConversion<OP> {
using fir::FIROpConversion<OP>::FIROpConversion;
using TypePair = typename fir::FIROpConversion<OP>::TypePair;
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
[flang] Add fir.dispatch code generation fir.dispatch code generation uses the binding table stored in the type descriptor. There is no runtime call involved. The binding table is always build from the parent type so the index of a specific binding is the same in the parent derived-type or in the extended type. Follow-up patches will deal cases not present here such as allocatable polymorphic entities or pointers. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D136189
2022-10-19 09:41:23 +02:00
static int getCFIAttr(fir::BaseBoxType boxTy) {
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
auto eleTy = boxTy.getEleTy();
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (mlir::isa<fir::PointerType>(eleTy))
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
return CFI_attribute_pointer;
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (mlir::isa<fir::HeapType>(eleTy))
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
return CFI_attribute_allocatable;
return CFI_attribute_other;
}
[flang] Fix array substring emboxing code generation The code generation of the fir.embox op creating descriptors for array substring with a non constant length base was using the substring length to compute the first dimension result stride. Fix it to use the input length instead. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D154086
2023-06-29 18:38:18 +02:00
mlir::Value getCharacterByteSize(mlir::Location loc,
mlir::ConversionPatternRewriter &rewriter,
fir::CharacterType charTy,
mlir::ValueRange lenParams) const {
auto i64Ty = mlir::IntegerType::get(rewriter.getContext(), 64);
mlir::Value size =
genTypeStrideInBytes(loc, i64Ty, rewriter, this->convertType(charTy));
if (charTy.hasConstantLen())
return size; // Length accounted for in the genTypeStrideInBytes GEP.
// Otherwise, multiply the single character size by the length.
assert(!lenParams.empty());
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
auto len64 = fir::FIROpConversion<OP>::integerCast(loc, rewriter, i64Ty,
lenParams.back());
[flang] Fix array substring emboxing code generation The code generation of the fir.embox op creating descriptors for array substring with a non constant length base was using the substring length to compute the first dimension result stride. Fix it to use the input length instead. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D154086
2023-06-29 18:38:18 +02:00
return rewriter.create<mlir::LLVM::MulOp>(loc, i64Ty, size, len64);
}
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
// Get the element size and CFI type code of the boxed value.
std::tuple<mlir::Value, mlir::Value> getSizeAndTypeCode(
mlir::Location loc, mlir::ConversionPatternRewriter &rewriter,
mlir::Type boxEleTy, mlir::ValueRange lenParams = {}) const {
[flang] Compute type allocation size based on the actual target representation. This change makes sure that we compute the element size and the byte stride based on the target representation of the element type. For example, when REAL*10 is mapped to x86_fp80 each element occupies 16 bytes rather than 10 because of the padding. Note that the size computation method used here actually returns the distance between two adjacent element of the *same* type in memory (which is equivalent to llvm::DataLayout::getTypeAllocSize()). It does not return the number of bytes that may be overwritten by storing a value of the specified type (e.g. what can be computed via llvm::DataLayout::getTypeStoreSize(), but not available in mlir::DataLayout). Differential Revision: https://reviews.llvm.org/D133508
2022-09-08 10:13:45 -07:00
auto i64Ty = mlir::IntegerType::get(rewriter.getContext(), 64);
[flang] REAL(KIND=3) and COMPLEX(KIND=3) descriptors Update descriptor generation to correctly set the `type` field for REAL(3) and COMPLEX(3) objects.
2023-04-14 11:54:07 -07:00
if (auto eleTy = fir::dyn_cast_ptrEleTy(boxEleTy))
boxEleTy = eleTy;
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (auto seqTy = mlir::dyn_cast<fir::SequenceType>(boxEleTy))
[flang] REAL(KIND=3) and COMPLEX(KIND=3) descriptors Update descriptor generation to correctly set the `type` field for REAL(3) and COMPLEX(3) objects.
2023-04-14 11:54:07 -07:00
return getSizeAndTypeCode(loc, rewriter, seqTy.getEleTy(), lenParams);
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (mlir::isa<mlir::NoneType>(
boxEleTy)) // unlimited polymorphic or assumed type
[flang] REAL(KIND=3) and COMPLEX(KIND=3) descriptors Update descriptor generation to correctly set the `type` field for REAL(3) and COMPLEX(3) objects.
2023-04-14 11:54:07 -07:00
return {rewriter.create<mlir::LLVM::ConstantOp>(loc, i64Ty, 0),
this->genConstantOffset(loc, rewriter, CFI_type_other)};
mlir::Value typeCodeVal = this->genConstantOffset(
loc, rewriter,
fir::getTypeCode(boxEleTy, this->lowerTy().getKindMap()));
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (fir::isa_integer(boxEleTy) ||
mlir::dyn_cast<fir::LogicalType>(boxEleTy) || fir::isa_real(boxEleTy) ||
fir::isa_complex(boxEleTy))
[flang] REAL(KIND=3) and COMPLEX(KIND=3) descriptors Update descriptor generation to correctly set the `type` field for REAL(3) and COMPLEX(3) objects.
2023-04-14 11:54:07 -07:00
return {genTypeStrideInBytes(loc, i64Ty, rewriter,
this->convertType(boxEleTy)),
typeCodeVal};
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (auto charTy = mlir::dyn_cast<fir::CharacterType>(boxEleTy))
[flang] Fix array substring emboxing code generation The code generation of the fir.embox op creating descriptors for array substring with a non constant length base was using the substring length to compute the first dimension result stride. Fix it to use the input length instead. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D154086
2023-06-29 18:38:18 +02:00
return {getCharacterByteSize(loc, rewriter, charTy, lenParams),
typeCodeVal};
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
if (fir::isa_ref_type(boxEleTy)) {
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
auto ptrTy = ::getLlvmPtrType(rewriter.getContext());
[flang] REAL(KIND=3) and COMPLEX(KIND=3) descriptors Update descriptor generation to correctly set the `type` field for REAL(3) and COMPLEX(3) objects.
2023-04-14 11:54:07 -07:00
return {genTypeStrideInBytes(loc, i64Ty, rewriter, ptrTy), typeCodeVal};
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
}
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (mlir::isa<fir::RecordType>(boxEleTy))
[flang] REAL(KIND=3) and COMPLEX(KIND=3) descriptors Update descriptor generation to correctly set the `type` field for REAL(3) and COMPLEX(3) objects.
2023-04-14 11:54:07 -07:00
return {genTypeStrideInBytes(loc, i64Ty, rewriter,
this->convertType(boxEleTy)),
typeCodeVal};
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
fir::emitFatalError(loc, "unhandled type in fir.box code generation");
}
/// Basic pattern to write a field in the descriptor
mlir::Value insertField(mlir::ConversionPatternRewriter &rewriter,
mlir::Location loc, mlir::Value dest,
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
llvm::ArrayRef<std::int64_t> fldIndexes,
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
mlir::Value value, bool bitcast = false) const {
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
auto boxTy = dest.getType();
auto fldTy = this->getBoxEleTy(boxTy, fldIndexes);
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
if (!bitcast)
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
value = this->integerCast(loc, rewriter, fldTy, value);
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
// bitcast are no-ops with LLVM opaque pointers.
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
return rewriter.create<mlir::LLVM::InsertValueOp>(loc, dest, value,
fldIndexes);
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
}
inline mlir::Value
insertBaseAddress(mlir::ConversionPatternRewriter &rewriter,
mlir::Location loc, mlir::Value dest,
mlir::Value base) const {
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
return insertField(rewriter, loc, dest, {kAddrPosInBox}, base,
/*bitCast=*/true);
}
inline mlir::Value insertLowerBound(mlir::ConversionPatternRewriter &rewriter,
mlir::Location loc, mlir::Value dest,
unsigned dim, mlir::Value lb) const {
return insertField(rewriter, loc, dest,
{kDimsPosInBox, dim, kDimLowerBoundPos}, lb);
}
inline mlir::Value insertExtent(mlir::ConversionPatternRewriter &rewriter,
mlir::Location loc, mlir::Value dest,
unsigned dim, mlir::Value extent) const {
return insertField(rewriter, loc, dest, {kDimsPosInBox, dim, kDimExtentPos},
extent);
}
inline mlir::Value insertStride(mlir::ConversionPatternRewriter &rewriter,
mlir::Location loc, mlir::Value dest,
unsigned dim, mlir::Value stride) const {
return insertField(rewriter, loc, dest, {kDimsPosInBox, dim, kDimStridePos},
stride);
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
}
/// Get the address of the type descriptor global variable that was created by
/// lowering for derived type \p recType.
[flang][cuda] Update CompilerGeneratedNames pass to work on gpu module (#120660) - Update `CompilerGeneratedNames` so it can perform renaming in gpu.module - Update Codegen so it look in the correct module for the type descriptor.
2024-12-19 19:07:00 -08:00
template <typename ModOpTy>
mlir::Value
getTypeDescriptor(ModOpTy mod, mlir::ConversionPatternRewriter &rewriter,
mlir::Location loc, fir::RecordType recType) const {
[flang] Support PDT type descriptors in codegen This change updates the mapping of derived types and type descriptor object names to support kind parametrized derived types (PDT). It moves the custom name mapping to the internal name utility. To improve robustness and error reporting, type descriptors are also now required to be generated in all compilation unit that manipulates derived types. The previous codegen relied on the fact that descriptors not defined in the current FIR module were available externally. Errors with missing type descriptors were only caught at link time. This patch makes derived type definition mandatory, except if the derived types are expected to not have derived type descriptors (builtin types), or if the newly added debug switch `--ignore-missing-type-desc` is set. In those cases, a null pointer is used as type descriptor pointer. The debug switch intends to help testing FIR to LLVM passes without having to bother providing type descriptor data structures that are normally built by the front-end. Differential Revision: https://reviews.llvm.org/D120804
2022-03-03 10:07:34 +01:00
std::string name =
[RFC][flang] Replace special symbols in uniqued global names. (#104859) This change addresses more "issues" as the one resolved in #71338. Some targets (e.g. NVPTX) do not accept global names containing `.`. In particular, the global variables created to represent the runtime information of derived types use `.` in their names. A derived type's descriptor object may be used in the device code, e.g. to initialize a descriptor of a variable of this type. Thus, the runtime type info objects may need to be compiled for the device. Moreover, at least the derived types' descriptor objects may need to be registered (think of `omp declare target`) for the host-device association so that the addendum pointer can be properly mapped to the device for descriptors using a derived type's descriptor as their addendum pointer. The registration implies knowing the name of the global variable in the device image so that proper host code can be created. So it is better to name the globals the same way for the host and the device. CompilerGeneratedNamesConversion pass renames all uniqued globals such that the special symbols (currently `.`) are replaced with `X`. The pass is supposed to be run for the host and the device. An option is added to FIR-to-LLVM conversion pass to indicate whether the new pass has been run before or not. This setting affects how the codegen computes the names of the derived types' descriptors for FIR derived types. fir::NameUniquer now allows `X` to be part of a name, because the name deconstruction may be applied to the mangled names after CompilerGeneratedNamesConversion pass.
2024-08-21 13:37:03 -07:00
this->options.typeDescriptorsRenamedForAssembly
? fir::NameUniquer::getTypeDescriptorAssemblyName(recType.getName())
: fir::NameUniquer::getTypeDescriptorName(recType.getName());
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::Type llvmPtrTy = ::getLlvmPtrType(mod.getContext());
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
if (auto global = mod.template lookupSymbol<fir::GlobalOp>(name)) {
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
return rewriter.create<mlir::LLVM::AddressOfOp>(loc, llvmPtrTy,
[mlir] Flip dialects to _Prefixed Following https://llvm.discourse.group/t/psa-ods-generated-accessors-will-change-to-have-a-get-prefix-update-you-apis/4476 these have been flipped to both for ~4 weeks, flipping to _Prefixed. Differential Revision: https://reviews.llvm.org/D115585
2021-12-11 13:27:11 -08:00
global.getSymName());
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
}
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
if (auto global = mod.template lookupSymbol<mlir::LLVM::GlobalOp>(name)) {
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
// The global may have already been translated to LLVM.
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
return rewriter.create<mlir::LLVM::AddressOfOp>(loc, llvmPtrTy,
[mlir] Flip dialects to _Prefixed Following https://llvm.discourse.group/t/psa-ods-generated-accessors-will-change-to-have-a-get-prefix-update-you-apis/4476 these have been flipped to both for ~4 weeks, flipping to _Prefixed. Differential Revision: https://reviews.llvm.org/D115585
2021-12-11 13:27:11 -08:00
global.getSymName());
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
}
[flang] Support PDT type descriptors in codegen This change updates the mapping of derived types and type descriptor object names to support kind parametrized derived types (PDT). It moves the custom name mapping to the internal name utility. To improve robustness and error reporting, type descriptors are also now required to be generated in all compilation unit that manipulates derived types. The previous codegen relied on the fact that descriptors not defined in the current FIR module were available externally. Errors with missing type descriptors were only caught at link time. This patch makes derived type definition mandatory, except if the derived types are expected to not have derived type descriptors (builtin types), or if the newly added debug switch `--ignore-missing-type-desc` is set. In those cases, a null pointer is used as type descriptor pointer. The debug switch intends to help testing FIR to LLVM passes without having to bother providing type descriptor data structures that are normally built by the front-end. Differential Revision: https://reviews.llvm.org/D120804
2022-03-03 10:07:34 +01:00
// Type info derived types do not have type descriptors since they are the
// types defining type descriptors.
if (!this->options.ignoreMissingTypeDescriptors &&
!fir::NameUniquer::belongsToModule(
name, Fortran::semantics::typeInfoBuiltinModule))
fir::emitFatalError(
loc, "runtime derived type info descriptor was not generated");
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
return rewriter.create<mlir::LLVM::ZeroOp>(loc, llvmPtrTy);
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
}
[flang][cuda] Update CompilerGeneratedNames pass to work on gpu module (#120660) - Update `CompilerGeneratedNames` so it can perform renaming in gpu.module - Update Codegen so it look in the correct module for the type descriptor.
2024-12-19 19:07:00 -08:00
template <typename ModOpTy>
mlir::Value populateDescriptor(mlir::Location loc, ModOpTy mod,
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
fir::BaseBoxType boxTy, mlir::Type inputType,
mlir::ConversionPatternRewriter &rewriter,
unsigned rank, mlir::Value eleSize,
[flang] Add allocator_idx attribute on fir.embox and fircg.ext_embox (#101212) #100690 introduces allocator registry with the ability to store allocator index in the descriptor. This patch adds an attribute to fir.embox and fircg.ext_embox to be able to set the allocator index while populating the descriptor fields.
2024-08-01 12:49:17 -07:00
mlir::Value cfiTy, mlir::Value typeDesc,
[flang] Read the extra field from the in box when doing reboxing (#102992) Updated version of #102686. The issue was that in some rebox case the addendum presence flag should be updated and not always taken from the "from" box. This is the case when reboxing a fir.class to a fir.box that doesn't require an addendum for example. Open a new review since there is a bit of additional code in the CodeGen part.
2024-08-14 11:23:56 -07:00
int allocatorIdx = kDefaultAllocator,
mlir::Value extraField = {}) const {
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
auto llvmBoxTy = this->lowerTy().convertBoxTypeAsStruct(boxTy, rank);
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
bool isUnlimitedPolymorphic = fir::isUnlimitedPolymorphicType(boxTy);
[flang] Use input type to recover the type desc when emboxing When emboxing to a polymorphic entity without a type source box, the type desc address must be retrived from the input type and not from the box type. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D142435
2023-01-24 14:46:11 +01:00
bool useInputType = fir::isPolymorphicType(boxTy) || isUnlimitedPolymorphic;
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
mlir::Value descriptor =
rewriter.create<mlir::LLVM::UndefOp>(loc, llvmBoxTy);
descriptor =
insertField(rewriter, loc, descriptor, {kElemLenPosInBox}, eleSize);
descriptor = insertField(rewriter, loc, descriptor, {kVersionPosInBox},
this->genI32Constant(loc, rewriter, CFI_VERSION));
descriptor = insertField(rewriter, loc, descriptor, {kRankPosInBox},
this->genI32Constant(loc, rewriter, rank));
descriptor = insertField(rewriter, loc, descriptor, {kTypePosInBox}, cfiTy);
descriptor =
insertField(rewriter, loc, descriptor, {kAttributePosInBox},
this->genI32Constant(loc, rewriter, getCFIAttr(boxTy)));
[flang] Add ability to have special allocator for descriptor data (#100690) This patch enhances the descriptor with the ability to have specialized allocator. The allocators are registered in a dedicated registry and the index of the desired allocator is stored in the descriptor. The default allocator, std::malloc, is registered at index 0. In order to have this allocator index in the descriptor, the f18Addendum field is repurposed to be able to hold the presence flag for the addendum (lsb) and the allocator index. Since this is a change in the semantic and name of the 7th field of the descriptor, the CFI_VERSION is bumped to the date of the initial change. This patch only adds the ability to have this features as part of the descriptor but does not add specific allocator yet. CUDA fortran will be the first user of this feature to allocate descriptor data in the different type of device memory base on the CUDA attribute. --------- Co-authored-by: Slava Zakharin <szakharin@nvidia.com>
2024-08-01 09:39:53 -07:00
[flang] Moving common polymorphic code into utility files Differential revision: https://reviews.llvm.org/D145530
2023-03-07 16:09:23 -08:00
const bool hasAddendum = fir::boxHasAddendum(boxTy);
[flang] Add allocator_idx attribute on fir.embox and fircg.ext_embox (#101212) #100690 introduces allocator registry with the ability to store allocator index in the descriptor. This patch adds an attribute to fir.embox and fircg.ext_embox to be able to set the allocator index while populating the descriptor fields.
2024-08-01 12:49:17 -07:00
[flang] Read the extra field from the in box when doing reboxing (#102992) Updated version of #102686. The issue was that in some rebox case the addendum presence flag should be updated and not always taken from the "from" box. This is the case when reboxing a fir.class to a fir.box that doesn't require an addendum for example. Open a new review since there is a bit of additional code in the CodeGen part.
2024-08-14 11:23:56 -07:00
if (extraField) {
// Make sure to set the addendum presence flag according to the
// destination box.
if (hasAddendum) {
auto maskAttr = mlir::IntegerAttr::get(
rewriter.getIntegerType(8, /*isSigned=*/false),
llvm::APInt(8, (uint64_t)_CFI_ADDENDUM_FLAG, /*isSigned=*/false));
mlir::LLVM::ConstantOp mask = rewriter.create<mlir::LLVM::ConstantOp>(
loc, rewriter.getI8Type(), maskAttr);
extraField = rewriter.create<mlir::LLVM::OrOp>(loc, extraField, mask);
} else {
auto maskAttr = mlir::IntegerAttr::get(
rewriter.getIntegerType(8, /*isSigned=*/false),
[flang] Set isSigned=true for negative constant (NFC) We're providing this as a negative signed value, so set the flag. Currently doesn't make a difference, but will assert in the future. Split out of https://github.com/llvm/llvm-project/pull/80309.
2024-09-05 15:17:25 +02:00
llvm::APInt(8, (uint64_t)~_CFI_ADDENDUM_FLAG, /*isSigned=*/true));
[flang] Read the extra field from the in box when doing reboxing (#102992) Updated version of #102686. The issue was that in some rebox case the addendum presence flag should be updated and not always taken from the "from" box. This is the case when reboxing a fir.class to a fir.box that doesn't require an addendum for example. Open a new review since there is a bit of additional code in the CodeGen part.
2024-08-14 11:23:56 -07:00
mlir::LLVM::ConstantOp mask = rewriter.create<mlir::LLVM::ConstantOp>(
loc, rewriter.getI8Type(), maskAttr);
extraField = rewriter.create<mlir::LLVM::AndOp>(loc, extraField, mask);
}
// Extra field value is provided so just use it.
descriptor =
insertField(rewriter, loc, descriptor, {kExtraPosInBox}, extraField);
} else {
// Compute the value of the extra field based on allocator_idx and
[Flang][NFC] Split runtime headers in preparation for cross-compilation. (#112188) Split some headers into headers for public and private declarations in preparation for #110217. Moving the runtime-private headers in runtime-private include directory will occur in #110298. * Do not use `sizeof(Descriptor)` in the compiler. The size of the descriptor is target-dependent while `sizeof(Descriptor)` is the size of the Descriptor for the host platform which might be too small when cross-compiling to a different platform. Another problem is that the emitted assembly ((cross-)compiling to the same target) is not identical between Flang's running on different systems. Moving the declaration of `class Descriptor` out of the included header will also reduce the amount of #included sources. * Do not use `sizeof(ArrayConstructorVector)` and `alignof(ArrayConstructorVector)` in the compiler. Same reason as with `Descriptor`. * Compute the descriptor's extra flags without instantiating a Descriptor. `Fortran::runtime::Descriptor` is defined in the runtime source, but not the compiler source. * Move `InquiryKeywordHashDecode` into runtime-private header. The function is defined in the runtime sources and trying to call it in the compiler would lead to a link-error. * Move allocator-kind magic numbers into common header. They are the only declarations out of `allocator-registry.h` in the compiler as well. This does not make Flang cross-compile ready yet, the main goal is to avoid transitive header dependencies from Flang to clang-rt. There are more assumptions that host platform is the same as the target platform.
2024-12-06 15:29:00 +01:00
// addendum present.
unsigned extra = allocatorIdx << _CFI_ALLOCATOR_IDX_SHIFT;
[flang] Read the extra field from the in box when doing reboxing (#102992) Updated version of #102686. The issue was that in some rebox case the addendum presence flag should be updated and not always taken from the "from" box. This is the case when reboxing a fir.class to a fir.box that doesn't require an addendum for example. Open a new review since there is a bit of additional code in the CodeGen part.
2024-08-14 11:23:56 -07:00
if (hasAddendum)
[Flang][NFC] Split runtime headers in preparation for cross-compilation. (#112188) Split some headers into headers for public and private declarations in preparation for #110217. Moving the runtime-private headers in runtime-private include directory will occur in #110298. * Do not use `sizeof(Descriptor)` in the compiler. The size of the descriptor is target-dependent while `sizeof(Descriptor)` is the size of the Descriptor for the host platform which might be too small when cross-compiling to a different platform. Another problem is that the emitted assembly ((cross-)compiling to the same target) is not identical between Flang's running on different systems. Moving the declaration of `class Descriptor` out of the included header will also reduce the amount of #included sources. * Do not use `sizeof(ArrayConstructorVector)` and `alignof(ArrayConstructorVector)` in the compiler. Same reason as with `Descriptor`. * Compute the descriptor's extra flags without instantiating a Descriptor. `Fortran::runtime::Descriptor` is defined in the runtime source, but not the compiler source. * Move `InquiryKeywordHashDecode` into runtime-private header. The function is defined in the runtime sources and trying to call it in the compiler would lead to a link-error. * Move allocator-kind magic numbers into common header. They are the only declarations out of `allocator-registry.h` in the compiler as well. This does not make Flang cross-compile ready yet, the main goal is to avoid transitive header dependencies from Flang to clang-rt. There are more assumptions that host platform is the same as the target platform.
2024-12-06 15:29:00 +01:00
extra |= _CFI_ADDENDUM_FLAG;
descriptor = insertField(rewriter, loc, descriptor, {kExtraPosInBox},
this->genI32Constant(loc, rewriter, extra));
[flang] Read the extra field from the in box when doing reboxing (#102992) Updated version of #102686. The issue was that in some rebox case the addendum presence flag should be updated and not always taken from the "from" box. This is the case when reboxing a fir.class to a fir.box that doesn't require an addendum for example. Open a new review since there is a bit of additional code in the CodeGen part.
2024-08-14 11:23:56 -07:00
}
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
if (hasAddendum) {
[flang] Carry dynamic type in fir.rebox code generation Load the pointer of the dynamic type descriptor from the original box and update the destination descriptor with this pointer. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D136618
2022-10-24 20:42:31 +02:00
unsigned typeDescFieldId = getTypeDescFieldId(boxTy);
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
if (!typeDesc) {
[flang] Use input type to recover the type desc when emboxing When emboxing to a polymorphic entity without a type source box, the type desc address must be retrived from the input type and not from the box type. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D142435
2023-01-24 14:46:11 +01:00
if (useInputType) {
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
mlir::Type innerType = fir::unwrapInnerType(inputType);
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (innerType && mlir::isa<fir::RecordType>(innerType)) {
auto recTy = mlir::dyn_cast<fir::RecordType>(innerType);
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
typeDesc = getTypeDescriptor(mod, rewriter, loc, recTy);
} else {
// Unlimited polymorphic type descriptor with no record type. Set
// type descriptor address to a clean state.
[mlir][llvm] Replace NullOp by ZeroOp (#67183) This revision replaces the LLVM dialect NullOp by the recently introduced ZeroOp. The ZeroOp is more generic in the sense that it represents zero values of any LLVM type rather than null pointers only. This is a follow to https://github.com/llvm/llvm-project/pull/65508
2023-09-25 11:11:52 +02:00
typeDesc = rewriter.create<mlir::LLVM::ZeroOp>(
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
loc, ::getLlvmPtrType(mod.getContext()));
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
}
} else {
[flang] Moving common polymorphic code into utility files Differential revision: https://reviews.llvm.org/D145530
2023-03-07 16:09:23 -08:00
typeDesc = getTypeDescriptor(mod, rewriter, loc,
fir::unwrapIfDerived(boxTy));
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
}
}
if (typeDesc)
descriptor =
insertField(rewriter, loc, descriptor, {typeDescFieldId}, typeDesc,
/*bitCast=*/true);
[flang] Do not leave length parameters uninitialized in descriptor addendums (#81858) Descriptor addendum have a field to hold length parameters (currently only one). This field is currently never used because flang does not lowered derived types with length parameters. However, leaving it uninitialized is causing bugs in code like gFTL where the code is trying to sort POINTERs (see [1]). More precisely, it is an issue when two pointers should compare equal (same base address), because the uninitialized values in the addendum may differ depending on the "stack history" and optimization level. Always initialized the length parameters field in the addendum to zero. [1]: https://github.com/Goddard-Fortran-Ecosystem/gFTL/blob/dc93a5fc2fe2b487590580d9f0a17d77ca3fe5c1/include/v1/templates/set_impl.inc#L312 The type being transferred to an integer array may look like: ``` TYPE :: localwrapper TYPE(T), POINTER :: item END TYPE localwrapper ``` Which in flang case ends-up transferring a descriptor to an integer array, the code in gFTL later compare the integer arrays. This logic is used when building set data structures in gFTL.
2024-02-16 08:51:03 +01:00
// Always initialize the length parameter field to zero to avoid issues
// with uninitialized values in Fortran code trying to compare physical
// representation of derived types with pointer/allocatable components.
// This has been seen in hashing algorithms using TRANSFER.
mlir::Value zero =
genConstantIndex(loc, rewriter.getI64Type(), rewriter, 0);
descriptor = insertField(rewriter, loc, descriptor,
{getLenParamFieldId(boxTy), 0}, zero);
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
}
return descriptor;
}
// Template used for fir::EmboxOp and fir::cg::XEmboxOp
template <typename BOX>
std::tuple<fir::BaseBoxType, mlir::Value, mlir::Value>
consDescriptorPrefix(BOX box, mlir::Type inputType,
mlir::ConversionPatternRewriter &rewriter, unsigned rank,
[flang] Fixed substr access in embox/rebox CodeGen. The code was using the original operand of the operation, while it should have been using the remapped operands via the adaptor. Differential Revision: https://reviews.llvm.org/D148587
2023-04-17 17:06:14 -07:00
[[maybe_unused]] mlir::ValueRange substrParams,
[flang] Carry the whole polymorphic box in PolymorphicValue Until now, only the address of the type descriptor was hold in a PolymorphicValue. In some cases, the element size and the type code are also needed when creating new polymorphic descriptors from an element of a polymorphic entity. This patch updates PolymorphicValue to carry the source descriptor from which the element is extracted. The source descriptor is then used when emboxing the element to a new polymorphic descriptor. This simplify the code done in D141274 and will be used when creating polymorphic temporary as well. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D141609
2023-01-12 17:59:18 +01:00
mlir::ValueRange lenParams, mlir::Value sourceBox = {},
mlir::Type sourceBoxType = {}) const {
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
auto loc = box.getLoc();
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
auto boxTy = mlir::dyn_cast<fir::BaseBoxType>(box.getType());
[flang] Use input type when emboxing/reboxing polymorphic entities When emboxing an entity to a polymorphic box, use the input type to compute the type code and element size as the box type is too generic. When reboxing a polymorphic box, get this information from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D139916
2022-12-13 09:44:01 +01:00
bool useInputType = fir::isPolymorphicType(boxTy) &&
!fir::isUnlimitedPolymorphicType(inputType);
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
llvm::SmallVector<mlir::Value> typeparams = lenParams;
if constexpr (!std::is_same_v<BOX, fir::EmboxOp>) {
if (!box.getSubstr().empty() && fir::hasDynamicSize(boxTy.getEleTy()))
[flang] Fixed substr access in embox/rebox CodeGen. The code was using the original operand of the operation, while it should have been using the remapped operands via the adaptor. Differential Revision: https://reviews.llvm.org/D148587
2023-04-17 17:06:14 -07:00
typeparams.push_back(substrParams[1]);
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
}
[flang] Add allocator_idx attribute on fir.embox and fircg.ext_embox (#101212) #100690 introduces allocator registry with the ability to store allocator index in the descriptor. This patch adds an attribute to fir.embox and fircg.ext_embox to be able to set the allocator index while populating the descriptor fields.
2024-08-01 12:49:17 -07:00
int allocatorIdx = 0;
if constexpr (std::is_same_v<BOX, fir::EmboxOp> ||
std::is_same_v<BOX, fir::cg::XEmboxOp>) {
if (box.getAllocatorIdx())
allocatorIdx = *box.getAllocatorIdx();
}
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
// Write each of the fields with the appropriate values.
[flang] Use input type when emboxing/reboxing polymorphic entities When emboxing an entity to a polymorphic box, use the input type to compute the type code and element size as the box type is too generic. When reboxing a polymorphic box, get this information from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D139916
2022-12-13 09:44:01 +01:00
// When emboxing an element to a polymorphic descriptor, use the
// input type since the destination descriptor type has not the exact
// information.
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
auto [eleSize, cfiTy] = getSizeAndTypeCode(
loc, rewriter, useInputType ? inputType : boxTy.getEleTy(), typeparams);
[flang] Handle emboxing of a fir.ref<none> to an unlimited polymorphic box When an array element is extracted from an unlimited polymorphic array, the emboxing of this element has to retrive the type code and element size from the initial array. This patch retrive this information through the extracted type descriptor. This situation can be found in code like: ``` subroutine sub1(a) class(*) :: a(:) select type (x=>a(1)) type is (integer) x = 10 end select end subroutine ``` Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D141274
2023-01-09 17:52:14 +01:00
[flang] Carry the whole polymorphic box in PolymorphicValue Until now, only the address of the type descriptor was hold in a PolymorphicValue. In some cases, the element size and the type code are also needed when creating new polymorphic descriptors from an element of a polymorphic entity. This patch updates PolymorphicValue to carry the source descriptor from which the element is extracted. The source descriptor is then used when emboxing the element to a new polymorphic descriptor. This simplify the code done in D141274 and will be used when creating polymorphic temporary as well. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D141609
2023-01-12 17:59:18 +01:00
mlir::Value typeDesc;
[flang] Read the extra field from the in box when doing reboxing (#102992) Updated version of #102686. The issue was that in some rebox case the addendum presence flag should be updated and not always taken from the "from" box. This is the case when reboxing a fir.class to a fir.box that doesn't require an addendum for example. Open a new review since there is a bit of additional code in the CodeGen part.
2024-08-14 11:23:56 -07:00
mlir::Value extraField;
[flang] Update createTempMutableBox to support polymorphic entities When creating temporary from a polymorphic entity, its dynamic type information must be carried over to the temporary. This patch updates createTempMutableBox to support passing a source_box from which the information will be carried over. This is tested on the spread intrinsic and follow-up patches will updates other temporary creation where needed. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D141667
2023-01-16 09:36:28 +01:00
// When emboxing to a polymorphic box, get the type descriptor, type code
// and element size from the source box if any.
if (fir::isPolymorphicType(boxTy) && sourceBox) {
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
TypePair sourceBoxTyPair = this->getBoxTypePair(sourceBoxType);
[flang] Carry the whole polymorphic box in PolymorphicValue Until now, only the address of the type descriptor was hold in a PolymorphicValue. In some cases, the element size and the type code are also needed when creating new polymorphic descriptors from an element of a polymorphic entity. This patch updates PolymorphicValue to carry the source descriptor from which the element is extracted. The source descriptor is then used when emboxing the element to a new polymorphic descriptor. This simplify the code done in D141274 and will be used when creating polymorphic temporary as well. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D141609
2023-01-12 17:59:18 +01:00
typeDesc =
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
this->loadTypeDescAddress(loc, sourceBoxTyPair, sourceBox, rewriter);
[flang] Carry the whole polymorphic box in PolymorphicValue Until now, only the address of the type descriptor was hold in a PolymorphicValue. In some cases, the element size and the type code are also needed when creating new polymorphic descriptors from an element of a polymorphic entity. This patch updates PolymorphicValue to carry the source descriptor from which the element is extracted. The source descriptor is then used when emboxing the element to a new polymorphic descriptor. This simplify the code done in D141274 and will be used when creating polymorphic temporary as well. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D141609
2023-01-12 17:59:18 +01:00
mlir::Type idxTy = this->lowerTy().indexType();
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
eleSize = this->getElementSizeFromBox(loc, idxTy, sourceBoxTyPair,
[flang] Generate TBAA information. This is initial version of TBAA information generation for Flang generated IR. The desired behavior is that TBAA type descriptors are generated for FIR types during FIR to LLVM types conversion, and then TBAA access tags are attached to memory accessing operations when they are converted to LLVM IR dialect. In the initial version the type conversion is not producing TBAA type descriptors, and all memory accesses are just partitioned into two sets of box and non-box accesses, which can never alias. The TBAA generation is enabled by default at >O0 optimization levels. TBAA generation may also be enabled via `apply-tbaa` option of `fir-to-llvm-ir` conversion pass. `-mllvm -disable-tbaa` engineering option allows disabling TBAA generation to override Flang's default (e.g. when -O1 is used). SPEC CPU2006/437.leslie3d speeds up by more than 2x on Icelake. Reviewed By: jeanPerier, clementval Differential Revision: https://reviews.llvm.org/D141820
2023-01-17 09:08:43 -08:00
sourceBox, rewriter);
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
cfiTy = this->getValueFromBox(loc, sourceBoxTyPair, sourceBox,
[flang] Generate TBAA information. This is initial version of TBAA information generation for Flang generated IR. The desired behavior is that TBAA type descriptors are generated for FIR types during FIR to LLVM types conversion, and then TBAA access tags are attached to memory accessing operations when they are converted to LLVM IR dialect. In the initial version the type conversion is not producing TBAA type descriptors, and all memory accesses are just partitioned into two sets of box and non-box accesses, which can never alias. The TBAA generation is enabled by default at >O0 optimization levels. TBAA generation may also be enabled via `apply-tbaa` option of `fir-to-llvm-ir` conversion pass. `-mllvm -disable-tbaa` engineering option allows disabling TBAA generation to override Flang's default (e.g. when -O1 is used). SPEC CPU2006/437.leslie3d speeds up by more than 2x on Icelake. Reviewed By: jeanPerier, clementval Differential Revision: https://reviews.llvm.org/D141820
2023-01-17 09:08:43 -08:00
cfiTy.getType(), rewriter, kTypePosInBox);
[flang] Read the extra field from the in box when doing reboxing (#102992) Updated version of #102686. The issue was that in some rebox case the addendum presence flag should be updated and not always taken from the "from" box. This is the case when reboxing a fir.class to a fir.box that doesn't require an addendum for example. Open a new review since there is a bit of additional code in the CodeGen part.
2024-08-14 11:23:56 -07:00
extraField =
this->getExtraFromBox(loc, sourceBoxTyPair, sourceBox, rewriter);
[flang] Handle emboxing of a fir.ref<none> to an unlimited polymorphic box When an array element is extracted from an unlimited polymorphic array, the emboxing of this element has to retrive the type code and element size from the initial array. This patch retrive this information through the extracted type descriptor. This situation can be found in code like: ``` subroutine sub1(a) class(*) :: a(:) select type (x=>a(1)) type is (integer) x = 10 end select end subroutine ``` Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D141274
2023-01-09 17:52:14 +01:00
}
[flang][cuda] Update CompilerGeneratedNames pass to work on gpu module (#120660) - Update `CompilerGeneratedNames` so it can perform renaming in gpu.module - Update Codegen so it look in the correct module for the type descriptor.
2024-12-19 19:07:00 -08:00
mlir::Value descriptor;
if (auto gpuMod = box->template getParentOfType<mlir::gpu::GPUModuleOp>())
descriptor = populateDescriptor(loc, gpuMod, boxTy, inputType, rewriter,
rank, eleSize, cfiTy, typeDesc,
allocatorIdx, extraField);
else if (auto mod = box->template getParentOfType<mlir::ModuleOp>())
descriptor = populateDescriptor(loc, mod, boxTy, inputType, rewriter,
rank, eleSize, cfiTy, typeDesc,
allocatorIdx, extraField);
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
return {boxTy, descriptor, eleSize};
}
std::tuple<fir::BaseBoxType, mlir::Value, mlir::Value>
consDescriptorPrefix(fir::cg::XReboxOp box, mlir::Value loweredBox,
mlir::ConversionPatternRewriter &rewriter, unsigned rank,
[flang] Fixed substr access in embox/rebox CodeGen. The code was using the original operand of the operation, while it should have been using the remapped operands via the adaptor. Differential Revision: https://reviews.llvm.org/D148587
2023-04-17 17:06:14 -07:00
mlir::ValueRange substrParams,
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
mlir::ValueRange lenParams,
mlir::Value typeDesc = {}) const {
auto loc = box.getLoc();
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
auto boxTy = mlir::dyn_cast<fir::BaseBoxType>(box.getType());
auto inputBoxTy = mlir::dyn_cast<fir::BaseBoxType>(box.getBox().getType());
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
auto inputBoxTyPair = this->getBoxTypePair(inputBoxTy);
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
llvm::SmallVector<mlir::Value> typeparams = lenParams;
if (!box.getSubstr().empty() && fir::hasDynamicSize(boxTy.getEleTy()))
[flang] Fixed substr access in embox/rebox CodeGen. The code was using the original operand of the operation, while it should have been using the remapped operands via the adaptor. Differential Revision: https://reviews.llvm.org/D148587
2023-04-17 17:06:14 -07:00
typeparams.push_back(substrParams[1]);
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
auto [eleSize, cfiTy] =
getSizeAndTypeCode(loc, rewriter, boxTy.getEleTy(), typeparams);
[flang] Add conditional rebox when passing fir.box to optional fir.class When a `!fir.box<>` is passed as an actual argument to an optional `!fir.class<>` dummy it needs a `fir.rebox` in order to propagate the dynamic type information. The `fir.rebox` needs to happen only on present argument. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D142340
2023-01-23 15:41:23 +01:00
// Reboxing to a polymorphic entity. eleSize and type code need to
[flang][NFC] Fix typo
2023-01-24 14:34:16 +01:00
// be retrieved from the initial box and propagated to the new box.
[flang] Add conditional rebox when passing fir.box to optional fir.class When a `!fir.box<>` is passed as an actual argument to an optional `!fir.class<>` dummy it needs a `fir.rebox` in order to propagate the dynamic type information. The `fir.rebox` needs to happen only on present argument. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D142340
2023-01-23 15:41:23 +01:00
// If the initial box has an addendum, the type desc must be propagated as
// well.
if (fir::isPolymorphicType(boxTy)) {
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
mlir::Type idxTy = this->lowerTy().indexType();
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
eleSize = this->getElementSizeFromBox(loc, idxTy, inputBoxTyPair,
loweredBox, rewriter);
cfiTy = this->getValueFromBox(loc, inputBoxTyPair, loweredBox,
cfiTy.getType(), rewriter, kTypePosInBox);
[flang] Add conditional rebox when passing fir.box to optional fir.class When a `!fir.box<>` is passed as an actual argument to an optional `!fir.class<>` dummy it needs a `fir.rebox` in order to propagate the dynamic type information. The `fir.rebox` needs to happen only on present argument. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D142340
2023-01-23 15:41:23 +01:00
// TODO: For initial box that are unlimited polymorphic entities, this
// code must be made conditional because unlimited polymorphic entities
// with intrinsic type spec does not have addendum.
[flang] Moving common polymorphic code into utility files Differential revision: https://reviews.llvm.org/D145530
2023-03-07 16:09:23 -08:00
if (fir::boxHasAddendum(inputBoxTy))
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
typeDesc = this->loadTypeDescAddress(loc, inputBoxTyPair, loweredBox,
rewriter);
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
}
[flang] Read the extra field from the in box when doing reboxing (#102992) Updated version of #102686. The issue was that in some rebox case the addendum presence flag should be updated and not always taken from the "from" box. This is the case when reboxing a fir.class to a fir.box that doesn't require an addendum for example. Open a new review since there is a bit of additional code in the CodeGen part.
2024-08-14 11:23:56 -07:00
mlir::Value extraField =
this->getExtraFromBox(loc, inputBoxTyPair, loweredBox, rewriter);
[flang][cuda] Update CompilerGeneratedNames pass to work on gpu module (#120660) - Update `CompilerGeneratedNames` so it can perform renaming in gpu.module - Update Codegen so it look in the correct module for the type descriptor.
2024-12-19 19:07:00 -08:00
mlir::Value descriptor;
if (auto gpuMod = box->template getParentOfType<mlir::gpu::GPUModuleOp>())
descriptor =
populateDescriptor(loc, gpuMod, boxTy, box.getBox().getType(),
rewriter, rank, eleSize, cfiTy, typeDesc,
/*allocatorIdx=*/kDefaultAllocator, extraField);
else if (auto mod = box->template getParentOfType<mlir::ModuleOp>())
descriptor =
populateDescriptor(loc, mod, boxTy, box.getBox().getType(), rewriter,
rank, eleSize, cfiTy, typeDesc,
/*allocatorIdx=*/kDefaultAllocator, extraField);
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
return {boxTy, descriptor, eleSize};
}
[flang] Merge GEPs in substring fir.embox codegen When computing the base addresses of an array slice to make a descriptor, codegen generated two LLVM GEPs. The first to compute the address of the base character element, and a second one to compute the substring base inside that element. The previous code did not care about getting the result of the first GEP right: it used the base array LLVM type as the result type. This used to work when opaque pointer were not enabled (the actual GEP result type was probably applied in some later pass). But with opaque pointers, the second GEP ends-up computing an offset of len*<LLVM array type> instead of len*<character width>. A previous attempt to fix the issue was done in D129079, but it does not cover the cases where the array slice contains subcomponents before the substring (e.g: array(:)%char_field(5:10)). This patch fix the issue by computing the actual GEP result type in codegen. There is also enough knowledge now so that a single GEP can be generated instead of two. Differential Revision: https://reviews.llvm.org/D129481
2022-07-12 09:26:16 +02:00
// Compute the base address of a fir.box given the indices from the slice.
// The indices from the "outer" dimensions (every dimension after the first
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
// one (included) that is not a compile time constant) must have been
[flang] Merge GEPs in substring fir.embox codegen When computing the base addresses of an array slice to make a descriptor, codegen generated two LLVM GEPs. The first to compute the address of the base character element, and a second one to compute the substring base inside that element. The previous code did not care about getting the result of the first GEP right: it used the base array LLVM type as the result type. This used to work when opaque pointer were not enabled (the actual GEP result type was probably applied in some later pass). But with opaque pointers, the second GEP ends-up computing an offset of len*<LLVM array type> instead of len*<character width>. A previous attempt to fix the issue was done in D129079, but it does not cover the cases where the array slice contains subcomponents before the substring (e.g: array(:)%char_field(5:10)). This patch fix the issue by computing the actual GEP result type in codegen. There is also enough knowledge now so that a single GEP can be generated instead of two. Differential Revision: https://reviews.llvm.org/D129481
2022-07-12 09:26:16 +02:00
// multiplied with the related extents and added together into \p outerOffset.
mlir::Value
genBoxOffsetGep(mlir::ConversionPatternRewriter &rewriter, mlir::Location loc,
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::Value base, mlir::Type llvmBaseObjectType,
mlir::Value outerOffset, mlir::ValueRange cstInteriorIndices,
[flang] Merge GEPs in substring fir.embox codegen When computing the base addresses of an array slice to make a descriptor, codegen generated two LLVM GEPs. The first to compute the address of the base character element, and a second one to compute the substring base inside that element. The previous code did not care about getting the result of the first GEP right: it used the base array LLVM type as the result type. This used to work when opaque pointer were not enabled (the actual GEP result type was probably applied in some later pass). But with opaque pointers, the second GEP ends-up computing an offset of len*<LLVM array type> instead of len*<character width>. A previous attempt to fix the issue was done in D129079, but it does not cover the cases where the array slice contains subcomponents before the substring (e.g: array(:)%char_field(5:10)). This patch fix the issue by computing the actual GEP result type in codegen. There is also enough knowledge now so that a single GEP can be generated instead of two. Differential Revision: https://reviews.llvm.org/D129481
2022-07-12 09:26:16 +02:00
mlir::ValueRange componentIndices,
mlir/tblgen: use std::optional in generation This is part of an effort to migrate from llvm::Optional to std::optional. This patch changes the way mlir-tblgen generates .inc files, and modifies tests and documentation appropriately. It is a "no compromises" patch, and doesn't leave the user with an unpleasant mix of llvm::Optional and std::optional. A non-trivial change has been made to ControlFlowInterfaces to split one constructor into two, relating to a build failure on Windows. See also: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 Signed-off-by: Ramkumar Ramachandra <r@artagnon.com> Differential Revision: https://reviews.llvm.org/D138934
2022-12-14 11:39:19 +01:00
std::optional<mlir::Value> substringOffset) const {
[mlir][flang] Make use of the new `GEPArg` builder of GEP Op to simplify code This is the follow up on https://reviews.llvm.org/D130730 which goes through upstream code and removes creating constant values in favour of using the constant indices in GEP directly. This leads to less and more readable code and more compact IR as well. Differential Revision: https://reviews.llvm.org/D130731
2022-07-29 01:00:22 +02:00
llvm::SmallVector<mlir::LLVM::GEPArg> gepArgs{outerOffset};
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::Type resultTy = llvmBaseObjectType;
[flang] Merge GEPs in substring fir.embox codegen When computing the base addresses of an array slice to make a descriptor, codegen generated two LLVM GEPs. The first to compute the address of the base character element, and a second one to compute the substring base inside that element. The previous code did not care about getting the result of the first GEP right: it used the base array LLVM type as the result type. This used to work when opaque pointer were not enabled (the actual GEP result type was probably applied in some later pass). But with opaque pointers, the second GEP ends-up computing an offset of len*<LLVM array type> instead of len*<character width>. A previous attempt to fix the issue was done in D129079, but it does not cover the cases where the array slice contains subcomponents before the substring (e.g: array(:)%char_field(5:10)). This patch fix the issue by computing the actual GEP result type in codegen. There is also enough knowledge now so that a single GEP can be generated instead of two. Differential Revision: https://reviews.llvm.org/D129481
2022-07-12 09:26:16 +02:00
// Fortran is column major, llvm GEP is row major: reverse the indices here.
for (mlir::Value interiorIndex : llvm::reverse(cstInteriorIndices)) {
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
auto arrayTy = mlir::dyn_cast<mlir::LLVM::LLVMArrayType>(resultTy);
[flang] Merge GEPs in substring fir.embox codegen When computing the base addresses of an array slice to make a descriptor, codegen generated two LLVM GEPs. The first to compute the address of the base character element, and a second one to compute the substring base inside that element. The previous code did not care about getting the result of the first GEP right: it used the base array LLVM type as the result type. This used to work when opaque pointer were not enabled (the actual GEP result type was probably applied in some later pass). But with opaque pointers, the second GEP ends-up computing an offset of len*<LLVM array type> instead of len*<character width>. A previous attempt to fix the issue was done in D129079, but it does not cover the cases where the array slice contains subcomponents before the substring (e.g: array(:)%char_field(5:10)). This patch fix the issue by computing the actual GEP result type in codegen. There is also enough knowledge now so that a single GEP can be generated instead of two. Differential Revision: https://reviews.llvm.org/D129481
2022-07-12 09:26:16 +02:00
if (!arrayTy)
fir::emitFatalError(
loc,
"corrupted GEP generated being generated in fir.embox/fir.rebox");
resultTy = arrayTy.getElementType();
gepArgs.push_back(interiorIndex);
}
[flang] Fix codegen of subcomponents' indexing Identify multidimensional array indices in subcomponents and convert them from column-major to row-major ordering. This fixes codegen for fircg.ext_array_coor, fircg.ext_embox and, possibly, fircg.ext_rebox. Fixes https://github.com/llvm/llvm-project/issues/62038 Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D154214
2023-06-29 14:46:58 +00:00
llvm::SmallVector<mlir::Value> gepIndices =
convertSubcomponentIndices(loc, resultTy, componentIndices, &resultTy);
gepArgs.append(gepIndices.begin(), gepIndices.end());
[flang] Merge GEPs in substring fir.embox codegen When computing the base addresses of an array slice to make a descriptor, codegen generated two LLVM GEPs. The first to compute the address of the base character element, and a second one to compute the substring base inside that element. The previous code did not care about getting the result of the first GEP right: it used the base array LLVM type as the result type. This used to work when opaque pointer were not enabled (the actual GEP result type was probably applied in some later pass). But with opaque pointers, the second GEP ends-up computing an offset of len*<LLVM array type> instead of len*<character width>. A previous attempt to fix the issue was done in D129079, but it does not cover the cases where the array slice contains subcomponents before the substring (e.g: array(:)%char_field(5:10)). This patch fix the issue by computing the actual GEP result type in codegen. There is also enough knowledge now so that a single GEP can be generated instead of two. Differential Revision: https://reviews.llvm.org/D129481
2022-07-12 09:26:16 +02:00
if (substringOffset) {
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (auto arrayTy = mlir::dyn_cast<mlir::LLVM::LLVMArrayType>(resultTy)) {
[flang] Merge GEPs in substring fir.embox codegen When computing the base addresses of an array slice to make a descriptor, codegen generated two LLVM GEPs. The first to compute the address of the base character element, and a second one to compute the substring base inside that element. The previous code did not care about getting the result of the first GEP right: it used the base array LLVM type as the result type. This used to work when opaque pointer were not enabled (the actual GEP result type was probably applied in some later pass). But with opaque pointers, the second GEP ends-up computing an offset of len*<LLVM array type> instead of len*<character width>. A previous attempt to fix the issue was done in D129079, but it does not cover the cases where the array slice contains subcomponents before the substring (e.g: array(:)%char_field(5:10)). This patch fix the issue by computing the actual GEP result type in codegen. There is also enough knowledge now so that a single GEP can be generated instead of two. Differential Revision: https://reviews.llvm.org/D129481
2022-07-12 09:26:16 +02:00
gepArgs.push_back(*substringOffset);
resultTy = arrayTy.getElementType();
} else {
// If the CHARACTER length is dynamic, the whole base type should have
// degenerated to an llvm.ptr<i[width]>, and there should not be any
// cstInteriorIndices/componentIndices. The substring offset can be
// added to the outterOffset since it applies on the same LLVM type.
if (gepArgs.size() != 1)
fir::emitFatalError(loc,
"corrupted substring GEP in fir.embox/fir.rebox");
[flang] Migrate away from PointerUnion::{is,get} (NFC) (#120880) Note that PointerUnion::{is,get} have been soft deprecated in PointerUnion.h: // FIXME: Replace the uses of is(), get() and dyn_cast() with // isa<T>, cast<T> and the llvm::dyn_cast<T> I'm not touching PointerUnion::dyn_cast for now because it's a bit complicated; we could blindly migrate it to dyn_cast_if_present, but we should probably use dyn_cast when the operand is known to be non-null.
2024-12-22 13:30:16 -08:00
mlir::Type outterOffsetTy =
llvm::cast<mlir::Value>(gepArgs[0]).getType();
[flang] Merge GEPs in substring fir.embox codegen When computing the base addresses of an array slice to make a descriptor, codegen generated two LLVM GEPs. The first to compute the address of the base character element, and a second one to compute the substring base inside that element. The previous code did not care about getting the result of the first GEP right: it used the base array LLVM type as the result type. This used to work when opaque pointer were not enabled (the actual GEP result type was probably applied in some later pass). But with opaque pointers, the second GEP ends-up computing an offset of len*<LLVM array type> instead of len*<character width>. A previous attempt to fix the issue was done in D129079, but it does not cover the cases where the array slice contains subcomponents before the substring (e.g: array(:)%char_field(5:10)). This patch fix the issue by computing the actual GEP result type in codegen. There is also enough knowledge now so that a single GEP can be generated instead of two. Differential Revision: https://reviews.llvm.org/D129481
2022-07-12 09:26:16 +02:00
mlir::Value cast =
this->integerCast(loc, rewriter, outterOffsetTy, *substringOffset);
[mlir][flang] Make use of the new `GEPArg` builder of GEP Op to simplify code This is the follow up on https://reviews.llvm.org/D130730 which goes through upstream code and removes creating constant values in favour of using the constant indices in GEP directly. This leads to less and more readable code and more compact IR as well. Differential Revision: https://reviews.llvm.org/D130731
2022-07-29 01:00:22 +02:00
gepArgs[0] = rewriter.create<mlir::LLVM::AddOp>(
[flang] Migrate away from PointerUnion::{is,get} (NFC) (#120880) Note that PointerUnion::{is,get} have been soft deprecated in PointerUnion.h: // FIXME: Replace the uses of is(), get() and dyn_cast() with // isa<T>, cast<T> and the llvm::dyn_cast<T> I'm not touching PointerUnion::dyn_cast for now because it's a bit complicated; we could blindly migrate it to dyn_cast_if_present, but we should probably use dyn_cast when the operand is known to be non-null.
2024-12-22 13:30:16 -08:00
loc, outterOffsetTy, llvm::cast<mlir::Value>(gepArgs[0]), cast);
[flang] Merge GEPs in substring fir.embox codegen When computing the base addresses of an array slice to make a descriptor, codegen generated two LLVM GEPs. The first to compute the address of the base character element, and a second one to compute the substring base inside that element. The previous code did not care about getting the result of the first GEP right: it used the base array LLVM type as the result type. This used to work when opaque pointer were not enabled (the actual GEP result type was probably applied in some later pass). But with opaque pointers, the second GEP ends-up computing an offset of len*<LLVM array type> instead of len*<character width>. A previous attempt to fix the issue was done in D129079, but it does not cover the cases where the array slice contains subcomponents before the substring (e.g: array(:)%char_field(5:10)). This patch fix the issue by computing the actual GEP result type in codegen. There is also enough knowledge now so that a single GEP can be generated instead of two. Differential Revision: https://reviews.llvm.org/D129481
2022-07-12 09:26:16 +02:00
}
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
}
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::Type llvmPtrTy = ::getLlvmPtrType(resultTy.getContext());
return rewriter.create<mlir::LLVM::GEPOp>(
loc, llvmPtrTy, llvmBaseObjectType, base, gepArgs);
[flang] Merge GEPs in substring fir.embox codegen When computing the base addresses of an array slice to make a descriptor, codegen generated two LLVM GEPs. The first to compute the address of the base character element, and a second one to compute the substring base inside that element. The previous code did not care about getting the result of the first GEP right: it used the base array LLVM type as the result type. This used to work when opaque pointer were not enabled (the actual GEP result type was probably applied in some later pass). But with opaque pointers, the second GEP ends-up computing an offset of len*<LLVM array type> instead of len*<character width>. A previous attempt to fix the issue was done in D129079, but it does not cover the cases where the array slice contains subcomponents before the substring (e.g: array(:)%char_field(5:10)). This patch fix the issue by computing the actual GEP result type in codegen. There is also enough knowledge now so that a single GEP can be generated instead of two. Differential Revision: https://reviews.llvm.org/D129481
2022-07-12 09:26:16 +02:00
}
template <typename BOX>
void
getSubcomponentIndices(BOX xbox, mlir::Value memref,
mlir::ValueRange operands,
mlir::SmallVectorImpl<mlir::Value> &indices) const {
// For each field in the path add the offset to base via the args list.
// In the most general case, some offsets must be computed since
// they are not be known until runtime.
if (fir::hasDynamicSize(fir::unwrapSequenceType(
fir::unwrapPassByRefType(memref.getType()))))
TODO(xbox.getLoc(),
"fir.embox codegen dynamic size component in derived type");
[flang][NFC] rename fircg op operand index accessors (#100584) fircg operations have xxxOffset members to give the operand index of operand xxx. This is a bit weird when looking at usage (e.g. `arrayCoor.shiftOffset` reads like it is shifting some offset). Rename them to getXxxOperandIndex.
2024-07-25 18:02:03 +02:00
indices.append(operands.begin() + xbox.getSubcomponentOperandIndex(),
operands.begin() + xbox.getSubcomponentOperandIndex() +
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
xbox.getSubcomponent().size());
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
}
[flang] Allow and use fir.rebox in fir.global The current lowering of initial target in fir.global is relying on how fir.box are created: instead of using a fir.rebox to add the POINTER attribute to the created descriptor, it is looking for a fir.embox defining operation and creating a copy of it with a different result types. The rational for doing so was that fir.rebox codegen was not possible inside fir.global because it expects to manipulate the input fir.box in memory, while objects cannot be manipulated in memory inside a fir.global region that must be constant foldable. But this approach has two problems: - it won't work with hlfir where fir.box may be created by more operations than fir.embox (e.g. hlfir.delcare or hlfir.designate). In general, looking for a precise defining op for a value is fragile. - manually copying and modifying an operation is risky: it is easy to forget copying some default operands (that could be added later). This patch modifies the helpers to get descriptor fields so that they can both operate on fir.box lowered in memory or in an llvm.struct value. This enables the usage of fir.rebox in fir.global op. The fallout in FIR tests is caused by the usage of constant index when creating GEP (because extractOp requires constant indices). MLIR builder uses i32 bit constant indices when non mlir::Value indices are passed to the MLIR GEP op builder. Previously, an 64 nist mlir constant value was created and passed to the GEP builder. In this case, the builder respect the value type when later generating the GEP. Given this changes impact the "dimension" index that can, per Fortran requirement, not be greated than 15, using a 32 bit index is just fine and actually simplify the MLIR LLVM IR generation. The fallout in lowering tests is caused by the introduction of the fir.rebox everytime an initial target is created. Differential Revision: https://reviews.llvm.org/D141136
2023-01-10 09:01:38 +01:00
static bool isInGlobalOp(mlir::ConversionPatternRewriter &rewriter) {
auto *thisBlock = rewriter.getInsertionBlock();
return thisBlock &&
mlir::isa<mlir::LLVM::GlobalOp>(thisBlock->getParentOp());
}
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
/// If the embox is not in a globalOp body, allocate storage for the box;
/// store the value inside and return the generated alloca. Return the input
/// value otherwise.
mlir::Value
placeInMemoryIfNotGlobalInit(mlir::ConversionPatternRewriter &rewriter,
[flang] Generate TBAA information. This is initial version of TBAA information generation for Flang generated IR. The desired behavior is that TBAA type descriptors are generated for FIR types during FIR to LLVM types conversion, and then TBAA access tags are attached to memory accessing operations when they are converted to LLVM IR dialect. In the initial version the type conversion is not producing TBAA type descriptors, and all memory accesses are just partitioned into two sets of box and non-box accesses, which can never alias. The TBAA generation is enabled by default at >O0 optimization levels. TBAA generation may also be enabled via `apply-tbaa` option of `fir-to-llvm-ir` conversion pass. `-mllvm -disable-tbaa` engineering option allows disabling TBAA generation to override Flang's default (e.g. when -O1 is used). SPEC CPU2006/437.leslie3d speeds up by more than 2x on Icelake. Reviewed By: jeanPerier, clementval Differential Revision: https://reviews.llvm.org/D141820
2023-01-17 09:08:43 -08:00
mlir::Location loc, mlir::Type boxTy,
[flang][cuda] Allocate descriptor in managed memory when emboxing device memory (#120485) When emboxing memory that comes from CUFMemAlloc, we need to allocate the descriptor in manage memory as it might be passed to a kernel.
2024-12-18 18:20:45 -08:00
mlir::Value boxValue,
bool needDeviceAllocation = false) const {
[flang] Allow and use fir.rebox in fir.global The current lowering of initial target in fir.global is relying on how fir.box are created: instead of using a fir.rebox to add the POINTER attribute to the created descriptor, it is looking for a fir.embox defining operation and creating a copy of it with a different result types. The rational for doing so was that fir.rebox codegen was not possible inside fir.global because it expects to manipulate the input fir.box in memory, while objects cannot be manipulated in memory inside a fir.global region that must be constant foldable. But this approach has two problems: - it won't work with hlfir where fir.box may be created by more operations than fir.embox (e.g. hlfir.delcare or hlfir.designate). In general, looking for a precise defining op for a value is fragile. - manually copying and modifying an operation is risky: it is easy to forget copying some default operands (that could be added later). This patch modifies the helpers to get descriptor fields so that they can both operate on fir.box lowered in memory or in an llvm.struct value. This enables the usage of fir.rebox in fir.global op. The fallout in FIR tests is caused by the usage of constant index when creating GEP (because extractOp requires constant indices). MLIR builder uses i32 bit constant indices when non mlir::Value indices are passed to the MLIR GEP op builder. Previously, an 64 nist mlir constant value was created and passed to the GEP builder. In this case, the builder respect the value type when later generating the GEP. Given this changes impact the "dimension" index that can, per Fortran requirement, not be greated than 15, using a 32 bit index is just fine and actually simplify the MLIR LLVM IR generation. The fallout in lowering tests is caused by the introduction of the fir.rebox everytime an initial target is created. Differential Revision: https://reviews.llvm.org/D141136
2023-01-10 09:01:38 +01:00
if (isInGlobalOp(rewriter))
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
return boxValue;
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::Type llvmBoxTy = boxValue.getType();
[flang][cuda] Allocate descriptor in managed memory when emboxing device memory (#120485) When emboxing memory that comes from CUFMemAlloc, we need to allocate the descriptor in manage memory as it might be passed to a kernel.
2024-12-18 18:20:45 -08:00
mlir::Value storage;
if (needDeviceAllocation) {
auto mod = boxValue.getDefiningOp()->getParentOfType<mlir::ModuleOp>();
auto baseBoxTy = mlir::dyn_cast<fir::BaseBoxType>(boxTy);
storage =
genCUFAllocDescriptor(loc, rewriter, mod, baseBoxTy, this->lowerTy());
} else {
storage = this->genAllocaAndAddrCastWithType(loc, llvmBoxTy, defaultAlign,
rewriter);
}
auto storeOp = rewriter.create<mlir::LLVM::StoreOp>(loc, boxValue, storage);
[flang] Generate TBAA information. This is initial version of TBAA information generation for Flang generated IR. The desired behavior is that TBAA type descriptors are generated for FIR types during FIR to LLVM types conversion, and then TBAA access tags are attached to memory accessing operations when they are converted to LLVM IR dialect. In the initial version the type conversion is not producing TBAA type descriptors, and all memory accesses are just partitioned into two sets of box and non-box accesses, which can never alias. The TBAA generation is enabled by default at >O0 optimization levels. TBAA generation may also be enabled via `apply-tbaa` option of `fir-to-llvm-ir` conversion pass. `-mllvm -disable-tbaa` engineering option allows disabling TBAA generation to override Flang's default (e.g. when -O1 is used). SPEC CPU2006/437.leslie3d speeds up by more than 2x on Icelake. Reviewed By: jeanPerier, clementval Differential Revision: https://reviews.llvm.org/D141820
2023-01-17 09:08:43 -08:00
this->attachTBAATag(storeOp, boxTy, boxTy, nullptr);
[flang][cuda] Allocate descriptor in managed memory when emboxing device memory (#120485) When emboxing memory that comes from CUFMemAlloc, we need to allocate the descriptor in manage memory as it might be passed to a kernel.
2024-12-18 18:20:45 -08:00
return storage;
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
}
[flang] Support non-index shape/shift/slice for CG box operations. (#124625) That is another problem uncovered during hlfir.reshape inlining, where the shape bits could be any integer type. This patch adds explicit convertions to `index` type where needed.
2025-01-28 09:38:33 -08:00
/// Compute the extent of a triplet slice (lb:ub:step).
mlir::Value computeTripletExtent(mlir::ConversionPatternRewriter &rewriter,
mlir::Location loc, mlir::Value lb,
mlir::Value ub, mlir::Value step,
mlir::Value zero, mlir::Type type) const {
lb = this->integerCast(loc, rewriter, type, lb);
ub = this->integerCast(loc, rewriter, type, ub);
step = this->integerCast(loc, rewriter, type, step);
zero = this->integerCast(loc, rewriter, type, zero);
mlir::Value extent = rewriter.create<mlir::LLVM::SubOp>(loc, type, ub, lb);
extent = rewriter.create<mlir::LLVM::AddOp>(loc, type, extent, step);
extent = rewriter.create<mlir::LLVM::SDivOp>(loc, type, extent, step);
// If the resulting extent is negative (`ub-lb` and `step` have different
// signs), zero must be returned instead.
auto cmp = rewriter.create<mlir::LLVM::ICmpOp>(
loc, mlir::LLVM::ICmpPredicate::sgt, extent, zero);
return rewriter.create<mlir::LLVM::SelectOp>(loc, cmp, extent, zero);
}
};
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
/// Create a generic box on a memory reference. This conversions lowers the
/// abstract box to the appropriate, initialized descriptor.
struct EmboxOpConversion : public EmboxCommonConversion<fir::EmboxOp> {
using EmboxCommonConversion::EmboxCommonConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
matchAndRewrite(fir::EmboxOp embox, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
[flang] Make code more homogenous in CodeGen This patch just make the code more similar in each conversion. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D129071
2022-07-04 21:16:13 +02:00
mlir::ValueRange operands = adaptor.getOperands();
[flang] Carry the whole polymorphic box in PolymorphicValue Until now, only the address of the type descriptor was hold in a PolymorphicValue. In some cases, the element size and the type code are also needed when creating new polymorphic descriptors from an element of a polymorphic entity. This patch updates PolymorphicValue to carry the source descriptor from which the element is extracted. The source descriptor is then used when emboxing the element to a new polymorphic descriptor. This simplify the code done in D141274 and will be used when creating polymorphic temporary as well. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D141609
2023-01-12 17:59:18 +01:00
mlir::Value sourceBox;
mlir::Type sourceBoxType;
if (embox.getSourceBox()) {
[flang][NFC] rename fircg op operand index accessors (#100584) fircg operations have xxxOffset members to give the operand index of operand xxx. This is a bit weird when looking at usage (e.g. `arrayCoor.shiftOffset` reads like it is shifting some offset). Rename them to getXxxOperandIndex.
2024-07-25 18:02:03 +02:00
sourceBox = operands[embox.getSourceBoxOperandIndex()];
[flang] Carry the whole polymorphic box in PolymorphicValue Until now, only the address of the type descriptor was hold in a PolymorphicValue. In some cases, the element size and the type code are also needed when creating new polymorphic descriptors from an element of a polymorphic entity. This patch updates PolymorphicValue to carry the source descriptor from which the element is extracted. The source descriptor is then used when emboxing the element to a new polymorphic descriptor. This simplify the code done in D141274 and will be used when creating polymorphic temporary as well. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D141609
2023-01-12 17:59:18 +01:00
sourceBoxType = embox.getSourceBox().getType();
}
[fir] Add fir.embox conversion Convert a `fir.embox` operation to LLVM IR dialect. A `fir.embox` is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. Current limitiation: alignment is set by default but should be retrieved in the specific target. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski Differential Revision: https://reviews.llvm.org/D113756 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-18 11:05:45 +01:00
assert(!embox.getShape() && "There should be no dims on this embox op");
[flang] Make code more homogenous in CodeGen This patch just make the code more similar in each conversion. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D129071
2022-07-04 21:16:13 +02:00
auto [boxTy, dest, eleSize] = consDescriptorPrefix(
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
embox, fir::unwrapRefType(embox.getMemref().getType()), rewriter,
[flang] Fixed substr access in embox/rebox CodeGen. The code was using the original operand of the operation, while it should have been using the remapped operands via the adaptor. Differential Revision: https://reviews.llvm.org/D148587
2023-04-17 17:06:14 -07:00
/*rank=*/0, /*substrParams=*/mlir::ValueRange{},
adaptor.getTypeparams(), sourceBox, sourceBoxType);
[flang] Make code more homogenous in CodeGen This patch just make the code more similar in each conversion. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D129071
2022-07-04 21:16:13 +02:00
dest = insertBaseAddress(rewriter, embox.getLoc(), dest, operands[0]);
[flang] Moving common polymorphic code into utility files Differential revision: https://reviews.llvm.org/D145530
2023-03-07 16:09:23 -08:00
if (fir::isDerivedTypeWithLenParams(boxTy)) {
[Flang] Replace notifyMatchFailure with TODO hard failures For unimplemented patterns we revert to using TODO hard failures instead of notifyMatchFailure. For fir.select_type revert to using mlir::emiterror. For the fir.embox TODO on a type with len params we cannot add a test since the type cannot be converted to llvm. Adding negative tests using not and checking for the error message. TODO exits with an error in a build without assertion but aborts in a build with assertions. Abort requires using not with the --crash option. The two different usages of not is handled by using a custom command %not_todo_cmd which is converted to not or not --crash depending on the presence or absence of assertions. Using llvm-config to check the presence of assertions. Reviewed By: clementval, awarzynski Differential Revision: https://reviews.llvm.org/D114371
2021-12-01 22:12:12 +00:00
TODO(embox.getLoc(),
"fir.embox codegen of derived with length parameters");
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::failure();
[Flang] Replace notifyMatchFailure with TODO hard failures For unimplemented patterns we revert to using TODO hard failures instead of notifyMatchFailure. For fir.select_type revert to using mlir::emiterror. For the fir.embox TODO on a type with len params we cannot add a test since the type cannot be converted to llvm. Adding negative tests using not and checking for the error message. TODO exits with an error in a build without assertion but aborts in a build with assertions. Abort requires using not with the --crash option. The two different usages of not is handled by using a custom command %not_todo_cmd which is converted to not or not --crash depending on the presence or absence of assertions. Using llvm-config to check the presence of assertions. Reviewed By: clementval, awarzynski Differential Revision: https://reviews.llvm.org/D114371
2021-12-01 22:12:12 +00:00
}
[flang] Generate TBAA information. This is initial version of TBAA information generation for Flang generated IR. The desired behavior is that TBAA type descriptors are generated for FIR types during FIR to LLVM types conversion, and then TBAA access tags are attached to memory accessing operations when they are converted to LLVM IR dialect. In the initial version the type conversion is not producing TBAA type descriptors, and all memory accesses are just partitioned into two sets of box and non-box accesses, which can never alias. The TBAA generation is enabled by default at >O0 optimization levels. TBAA generation may also be enabled via `apply-tbaa` option of `fir-to-llvm-ir` conversion pass. `-mllvm -disable-tbaa` engineering option allows disabling TBAA generation to override Flang's default (e.g. when -O1 is used). SPEC CPU2006/437.leslie3d speeds up by more than 2x on Icelake. Reviewed By: jeanPerier, clementval Differential Revision: https://reviews.llvm.org/D141820
2023-01-17 09:08:43 -08:00
auto result =
placeInMemoryIfNotGlobalInit(rewriter, embox.getLoc(), boxTy, dest);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
rewriter.replaceOp(embox, result);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[Flang] Notify conversion failure for Proc ops, types Add the FIR to LLVM conversion patterns for the BoxProcHostOp, EmboxProcOp, and UnboxProcOp ops and the boxproc type. These are currently unimplemented. Implementation will come at a later time when support for Fortran 2003 procedure pointer feature is added. Reviewed By: clementval, rovka Differential Revision: https://reviews.llvm.org/D113879 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-18 11:26:53 +00:00
}
};
[flang][cuda] Allocate descriptor in managed memory when memref is a block argument (#123829)
2025-01-21 17:20:46 -08:00
static bool isDeviceAllocation(mlir::Value val, mlir::Value adaptorVal) {
[flang][cuda] Correctly allocate descriptor in managed memory when reboxing (#120795) Reboxing might create a new in memory descriptor. If this one was allocate with managed memory, allocate the new one in managed memory as well.
2024-12-20 13:32:31 -08:00
if (auto loadOp = mlir::dyn_cast_or_null<fir::LoadOp>(val.getDefiningOp()))
[flang][cuda] Allocate descriptor in managed memory when memref is a block argument (#123829)
2025-01-21 17:20:46 -08:00
return isDeviceAllocation(loadOp.getMemref(), {});
[flang][cuda] Create descriptor in managed memory when emboxing fir.box_addr value (#120980)
2024-12-23 09:52:59 -08:00
if (auto boxAddrOp =
mlir::dyn_cast_or_null<fir::BoxAddrOp>(val.getDefiningOp()))
[flang][cuda] Allocate descriptor in managed memory when memref is a block argument (#123829)
2025-01-21 17:20:46 -08:00
return isDeviceAllocation(boxAddrOp.getVal(), {});
[flang][cuda] Allocate descriptor in managed memory when emboxing device memory (#120485) When emboxing memory that comes from CUFMemAlloc, we need to allocate the descriptor in manage memory as it might be passed to a kernel.
2024-12-18 18:20:45 -08:00
if (auto convertOp =
mlir::dyn_cast_or_null<fir::ConvertOp>(val.getDefiningOp()))
[flang][cuda] Allocate descriptor in managed memory when memref is a block argument (#123829)
2025-01-21 17:20:46 -08:00
return isDeviceAllocation(convertOp.getValue(), {});
if (!val.getDefiningOp() && adaptorVal) {
if (auto blockArg = llvm::cast<mlir::BlockArgument>(adaptorVal)) {
if (blockArg.getOwner() && blockArg.getOwner()->getParentOp() &&
blockArg.getOwner()->isEntryBlock()) {
if (auto func = mlir::dyn_cast_or_null<mlir::FunctionOpInterface>(
*blockArg.getOwner()->getParentOp())) {
auto argAttrs = func.getArgAttrs(blockArg.getArgNumber());
for (auto attr : argAttrs) {
if (attr.getName().getValue().ends_with(cuf::getDataAttrName())) {
auto dataAttr =
mlir::dyn_cast<cuf::DataAttributeAttr>(attr.getValue());
if (dataAttr.getValue() != cuf::DataAttribute::Pinned &&
dataAttr.getValue() != cuf::DataAttribute::Unified)
return true;
}
}
}
}
}
}
[flang][cuda] Allocate descriptor in managed memory when emboxing device memory (#120485) When emboxing memory that comes from CUFMemAlloc, we need to allocate the descriptor in manage memory as it might be passed to a kernel.
2024-12-18 18:20:45 -08:00
if (auto callOp = mlir::dyn_cast_or_null<fir::CallOp>(val.getDefiningOp()))
if (callOp.getCallee() &&
[flang][cuda] Correctly allocate descriptor in managed memory when reboxing (#120795) Reboxing might create a new in memory descriptor. If this one was allocate with managed memory, allocate the new one in managed memory as well.
2024-12-20 13:32:31 -08:00
(callOp.getCallee().value().getRootReference().getValue().starts_with(
RTNAME_STRING(CUFMemAlloc)) ||
callOp.getCallee().value().getRootReference().getValue().starts_with(
[flang][cuda][NFC] Fix typo in CUFAllocDescriptor (#120797) Missing `r` in the function name.
2024-12-20 13:57:47 -08:00
RTNAME_STRING(CUFAllocDescriptor))))
[flang][cuda] Allocate descriptor in managed memory when emboxing device memory (#120485) When emboxing memory that comes from CUFMemAlloc, we need to allocate the descriptor in manage memory as it might be passed to a kernel.
2024-12-18 18:20:45 -08:00
return true;
return false;
}
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
/// Create a generic box on a memory reference.
struct XEmboxOpConversion : public EmboxCommonConversion<fir::cg::XEmboxOp> {
using EmboxCommonConversion::EmboxCommonConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
matchAndRewrite(fir::cg::XEmboxOp xbox, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
mlir::ValueRange operands = adaptor.getOperands();
[flang] Carry the whole polymorphic box in PolymorphicValue Until now, only the address of the type descriptor was hold in a PolymorphicValue. In some cases, the element size and the type code are also needed when creating new polymorphic descriptors from an element of a polymorphic entity. This patch updates PolymorphicValue to carry the source descriptor from which the element is extracted. The source descriptor is then used when emboxing the element to a new polymorphic descriptor. This simplify the code done in D141274 and will be used when creating polymorphic temporary as well. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D141609
2023-01-12 17:59:18 +01:00
mlir::Value sourceBox;
mlir::Type sourceBoxType;
if (xbox.getSourceBox()) {
[flang][NFC] rename fircg op operand index accessors (#100584) fircg operations have xxxOffset members to give the operand index of operand xxx. This is a bit weird when looking at usage (e.g. `arrayCoor.shiftOffset` reads like it is shifting some offset). Rename them to getXxxOperandIndex.
2024-07-25 18:02:03 +02:00
sourceBox = operands[xbox.getSourceBoxOperandIndex()];
[flang] Carry the whole polymorphic box in PolymorphicValue Until now, only the address of the type descriptor was hold in a PolymorphicValue. In some cases, the element size and the type code are also needed when creating new polymorphic descriptors from an element of a polymorphic entity. This patch updates PolymorphicValue to carry the source descriptor from which the element is extracted. The source descriptor is then used when emboxing the element to a new polymorphic descriptor. This simplify the code done in D141274 and will be used when creating polymorphic temporary as well. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D141609
2023-01-12 17:59:18 +01:00
sourceBoxType = xbox.getSourceBox().getType();
}
[flang] Fix array substring emboxing code generation The code generation of the fir.embox op creating descriptors for array substring with a non constant length base was using the substring length to compute the first dimension result stride. Fix it to use the input length instead. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D154086
2023-06-29 18:38:18 +02:00
auto [boxTy, dest, resultEleSize] = consDescriptorPrefix(
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
xbox, fir::unwrapRefType(xbox.getMemref().getType()), rewriter,
[flang] Fixed substr access in embox/rebox CodeGen. The code was using the original operand of the operation, while it should have been using the remapped operands via the adaptor. Differential Revision: https://reviews.llvm.org/D148587
2023-04-17 17:06:14 -07:00
xbox.getOutRank(), adaptor.getSubstr(), adaptor.getLenParams(),
[flang] Carry the whole polymorphic box in PolymorphicValue Until now, only the address of the type descriptor was hold in a PolymorphicValue. In some cases, the element size and the type code are also needed when creating new polymorphic descriptors from an element of a polymorphic entity. This patch updates PolymorphicValue to carry the source descriptor from which the element is extracted. The source descriptor is then used when emboxing the element to a new polymorphic descriptor. This simplify the code done in D141274 and will be used when creating polymorphic temporary as well. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D141609
2023-01-12 17:59:18 +01:00
sourceBox, sourceBoxType);
[flang] Make code more homogenous in CodeGen This patch just make the code more similar in each conversion. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D129071
2022-07-04 21:16:13 +02:00
// Generate the triples in the dims field of the descriptor
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
auto i64Ty = mlir::IntegerType::get(xbox.getContext(), 64);
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
assert(!xbox.getShape().empty() && "must have a shape");
[flang][NFC] rename fircg op operand index accessors (#100584) fircg operations have xxxOffset members to give the operand index of operand xxx. This is a bit weird when looking at usage (e.g. `arrayCoor.shiftOffset` reads like it is shifting some offset). Rename them to getXxxOperandIndex.
2024-07-25 18:02:03 +02:00
unsigned shapeOffset = xbox.getShapeOperandIndex();
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
bool hasShift = !xbox.getShift().empty();
[flang][NFC] rename fircg op operand index accessors (#100584) fircg operations have xxxOffset members to give the operand index of operand xxx. This is a bit weird when looking at usage (e.g. `arrayCoor.shiftOffset` reads like it is shifting some offset). Rename them to getXxxOperandIndex.
2024-07-25 18:02:03 +02:00
unsigned shiftOffset = xbox.getShiftOperandIndex();
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
bool hasSlice = !xbox.getSlice().empty();
[flang][NFC] rename fircg op operand index accessors (#100584) fircg operations have xxxOffset members to give the operand index of operand xxx. This is a bit weird when looking at usage (e.g. `arrayCoor.shiftOffset` reads like it is shifting some offset). Rename them to getXxxOperandIndex.
2024-07-25 18:02:03 +02:00
unsigned sliceOffset = xbox.getSliceOperandIndex();
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
mlir::Location loc = xbox.getLoc();
mlir::Value zero = genConstantIndex(loc, i64Ty, rewriter, 0);
mlir::Value one = genConstantIndex(loc, i64Ty, rewriter, 1);
mlir::Value prevPtrOff = one;
mlir::Type eleTy = boxTy.getEleTy();
const unsigned rank = xbox.getRank();
[flang] Merge GEPs in substring fir.embox codegen When computing the base addresses of an array slice to make a descriptor, codegen generated two LLVM GEPs. The first to compute the address of the base character element, and a second one to compute the substring base inside that element. The previous code did not care about getting the result of the first GEP right: it used the base array LLVM type as the result type. This used to work when opaque pointer were not enabled (the actual GEP result type was probably applied in some later pass). But with opaque pointers, the second GEP ends-up computing an offset of len*<LLVM array type> instead of len*<character width>. A previous attempt to fix the issue was done in D129079, but it does not cover the cases where the array slice contains subcomponents before the substring (e.g: array(:)%char_field(5:10)). This patch fix the issue by computing the actual GEP result type in codegen. There is also enough knowledge now so that a single GEP can be generated instead of two. Differential Revision: https://reviews.llvm.org/D129481
2022-07-12 09:26:16 +02:00
llvm::SmallVector<mlir::Value> cstInteriorIndices;
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
unsigned constRows = 0;
mlir::Value ptrOffset = zero;
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
mlir::Type memEleTy = fir::dyn_cast_ptrEleTy(xbox.getMemref().getType());
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
assert(mlir::isa<fir::SequenceType>(memEleTy));
auto seqTy = mlir::cast<fir::SequenceType>(memEleTy);
[flang] Fix bug in character casting. Add missing sext/trunc in code gen. This patch is part of the upstreaming effort from fir-dev branch. It also ensures all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D128047 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2022-06-17 16:09:32 +02:00
mlir::Type seqEleTy = seqTy.getEleTy();
// Adjust the element scaling factor if the element is a dependent type.
if (fir::hasDynamicSize(seqEleTy)) {
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (auto charTy = mlir::dyn_cast<fir::CharacterType>(seqEleTy)) {
[flang] Fixed slice offset computation in XEmbox codegen. For character type with unknown length we end up generating a GEP with the base type `llvm.ptr<i[width]>`. The GEP produces the address of the first element of the slice, and it should be using the offset computed in the number of characters, while we were providing the offset in bytes. Simple reproducer fails with and w/o HLFIR: ``` program test integer,parameter :: ck = 4 character(:,ck),allocatable :: res(:,:) allocate(character(3,ck) :: res(2,2)) res(1,1) = ck_'111' res(1,2) = ck_'222' res(2,1) = ck_'333' res(2,2) = ck_'444' call check(res) contains subroutine check(res) character(:,ck),allocatable :: res(:,:) print *, res(2,:) end subroutine check end program test ``` Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D156849
2023-08-02 09:43:19 -07:00
// The GEP pointer type decays to llvm.ptr<i[width]>.
// The scaling factor is the runtime value of the length.
assert(!adaptor.getLenParams().empty());
prevPtrOff = FIROpConversion::integerCast(
loc, rewriter, i64Ty, adaptor.getLenParams().back());
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
} else if (mlir::isa<fir::RecordType>(seqEleTy)) {
[flang] Fix bug in character casting. Add missing sext/trunc in code gen. This patch is part of the upstreaming effort from fir-dev branch. It also ensures all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D128047 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2022-06-17 16:09:32 +02:00
// prevPtrOff = ;
TODO(loc, "generate call to calculate size of PDT");
} else {
fir::emitFatalError(loc, "unexpected dynamic type");
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
}
[flang] Fix bug in character casting. Add missing sext/trunc in code gen. This patch is part of the upstreaming effort from fir-dev branch. It also ensures all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D128047 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2022-06-17 16:09:32 +02:00
} else {
constRows = seqTy.getConstantRows();
}
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
const auto hasSubcomp = !xbox.getSubcomponent().empty();
const bool hasSubstr = !xbox.getSubstr().empty();
[flang] Compute type allocation size based on the actual target representation. This change makes sure that we compute the element size and the byte stride based on the target representation of the element type. For example, when REAL*10 is mapped to x86_fp80 each element occupies 16 bytes rather than 10 because of the padding. Note that the size computation method used here actually returns the distance between two adjacent element of the *same* type in memory (which is equivalent to llvm::DataLayout::getTypeAllocSize()). It does not return the number of bytes that may be overwritten by storing a value of the specified type (e.g. what can be computed via llvm::DataLayout::getTypeStoreSize(), but not available in mlir::DataLayout). Differential Revision: https://reviews.llvm.org/D133508
2022-09-08 10:13:45 -07:00
// Initial element stride that will be use to compute the step in
[flang] Fix array substring emboxing code generation The code generation of the fir.embox op creating descriptors for array substring with a non constant length base was using the substring length to compute the first dimension result stride. Fix it to use the input length instead. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D154086
2023-06-29 18:38:18 +02:00
// each dimension. Initially, this is the size of the input element.
// Note that when there are no components/substring, the resultEleSize
// that was previously computed matches the input element size.
mlir::Value prevDimByteStride = resultEleSize;
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
if (hasSubcomp) {
// We have a subcomponent. The step value needs to be the number of
// bytes per element (which is a derived type).
[flang] Compute type allocation size based on the actual target representation. This change makes sure that we compute the element size and the byte stride based on the target representation of the element type. For example, when REAL*10 is mapped to x86_fp80 each element occupies 16 bytes rather than 10 because of the padding. Note that the size computation method used here actually returns the distance between two adjacent element of the *same* type in memory (which is equivalent to llvm::DataLayout::getTypeAllocSize()). It does not return the number of bytes that may be overwritten by storing a value of the specified type (e.g. what can be computed via llvm::DataLayout::getTypeStoreSize(), but not available in mlir::DataLayout). Differential Revision: https://reviews.llvm.org/D133508
2022-09-08 10:13:45 -07:00
prevDimByteStride =
genTypeStrideInBytes(loc, i64Ty, rewriter, convertType(seqEleTy));
[flang] Fix bug in character casting. Add missing sext/trunc in code gen. This patch is part of the upstreaming effort from fir-dev branch. It also ensures all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D128047 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2022-06-17 16:09:32 +02:00
} else if (hasSubstr) {
// We have a substring. The step value needs to be the number of bytes
// per CHARACTER element.
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
auto charTy = mlir::cast<fir::CharacterType>(seqEleTy);
[flang] Fix bug in character casting. Add missing sext/trunc in code gen. This patch is part of the upstreaming effort from fir-dev branch. It also ensures all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D128047 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2022-06-17 16:09:32 +02:00
if (fir::hasDynamicSize(charTy)) {
[flang] Fixed slice offset computation in XEmbox codegen. For character type with unknown length we end up generating a GEP with the base type `llvm.ptr<i[width]>`. The GEP produces the address of the first element of the slice, and it should be using the offset computed in the number of characters, while we were providing the offset in bytes. Simple reproducer fails with and w/o HLFIR: ``` program test integer,parameter :: ck = 4 character(:,ck),allocatable :: res(:,:) allocate(character(3,ck) :: res(2,2)) res(1,1) = ck_'111' res(1,2) = ck_'222' res(2,1) = ck_'333' res(2,2) = ck_'444' call check(res) contains subroutine check(res) character(:,ck),allocatable :: res(:,:) print *, res(2,:) end subroutine check end program test ``` Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D156849
2023-08-02 09:43:19 -07:00
prevDimByteStride =
getCharacterByteSize(loc, rewriter, charTy, adaptor.getLenParams());
[flang] Fix bug in character casting. Add missing sext/trunc in code gen. This patch is part of the upstreaming effort from fir-dev branch. It also ensures all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D128047 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2022-06-17 16:09:32 +02:00
} else {
prevDimByteStride = genConstantIndex(
loc, i64Ty, rewriter,
charTy.getLen() * lowerTy().characterBitsize(charTy) / 8);
}
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
}
// Process the array subspace arguments (shape, shift, etc.), if any,
// translating everything to values in the descriptor wherever the entity
// has a dynamic array dimension.
for (unsigned di = 0, descIdx = 0; di < rank; ++di) {
[flang] Support non-index shape/shift/slice for CG box operations. (#124625) That is another problem uncovered during hlfir.reshape inlining, where the shape bits could be any integer type. This patch adds explicit convertions to `index` type where needed.
2025-01-28 09:38:33 -08:00
mlir::Value extent =
integerCast(loc, rewriter, i64Ty, operands[shapeOffset]);
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
mlir::Value outerExtent = extent;
bool skipNext = false;
if (hasSlice) {
[flang] Support non-index shape/shift/slice for CG box operations. (#124625) That is another problem uncovered during hlfir.reshape inlining, where the shape bits could be any integer type. This patch adds explicit convertions to `index` type where needed.
2025-01-28 09:38:33 -08:00
mlir::Value off =
integerCast(loc, rewriter, i64Ty, operands[sliceOffset]);
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
mlir::Value adj = one;
if (hasShift)
[flang] Support non-index shape/shift/slice for CG box operations. (#124625) That is another problem uncovered during hlfir.reshape inlining, where the shape bits could be any integer type. This patch adds explicit convertions to `index` type where needed.
2025-01-28 09:38:33 -08:00
adj = integerCast(loc, rewriter, i64Ty, operands[shiftOffset]);
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
auto ao = rewriter.create<mlir::LLVM::SubOp>(loc, i64Ty, off, adj);
if (constRows > 0) {
[flang] Merge GEPs in substring fir.embox codegen When computing the base addresses of an array slice to make a descriptor, codegen generated two LLVM GEPs. The first to compute the address of the base character element, and a second one to compute the substring base inside that element. The previous code did not care about getting the result of the first GEP right: it used the base array LLVM type as the result type. This used to work when opaque pointer were not enabled (the actual GEP result type was probably applied in some later pass). But with opaque pointers, the second GEP ends-up computing an offset of len*<LLVM array type> instead of len*<character width>. A previous attempt to fix the issue was done in D129079, but it does not cover the cases where the array slice contains subcomponents before the substring (e.g: array(:)%char_field(5:10)). This patch fix the issue by computing the actual GEP result type in codegen. There is also enough knowledge now so that a single GEP can be generated instead of two. Differential Revision: https://reviews.llvm.org/D129481
2022-07-12 09:26:16 +02:00
cstInteriorIndices.push_back(ao);
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
} else {
auto dimOff =
rewriter.create<mlir::LLVM::MulOp>(loc, i64Ty, ao, prevPtrOff);
ptrOffset =
rewriter.create<mlir::LLVM::AddOp>(loc, i64Ty, dimOff, ptrOffset);
}
if (mlir::isa_and_nonnull<fir::UndefOp>(
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
xbox.getSlice()[3 * di + 1].getDefiningOp())) {
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
// This dimension contains a scalar expression in the array slice op.
// The dimension is loop invariant, will be dropped, and will not
// appear in the descriptor.
skipNext = true;
}
}
if (!skipNext) {
[flang] Fix bug in character casting. Add missing sext/trunc in code gen. This patch is part of the upstreaming effort from fir-dev branch. It also ensures all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D128047 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2022-06-17 16:09:32 +02:00
// store extent
[flang][codegen] ensure descriptor lower bounds are LBOUND compliant Follow-up of https://reviews.llvm.org/D121488 to ensure all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. Both fir.xrebox and fir.xembox codegen is updated to enforce this constraint. Also upstream the "normalized lower bound" attribute that was added in fir-dev since embox codegen was upstreamed, it is conflicting with this patch otherwise. Differential Revision: https://reviews.llvm.org/D122419
2022-03-25 09:02:48 +01:00
if (hasSlice)
extent = computeTripletExtent(rewriter, loc, operands[sliceOffset],
operands[sliceOffset + 1],
operands[sliceOffset + 2], zero, i64Ty);
[flang] Fix bug in character casting. Add missing sext/trunc in code gen. This patch is part of the upstreaming effort from fir-dev branch. It also ensures all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D128047 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2022-06-17 16:09:32 +02:00
// Lower bound is normalized to 0 for BIND(C) interoperability.
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
mlir::Value lb = zero;
[flang][codegen] ensure descriptor lower bounds are LBOUND compliant Follow-up of https://reviews.llvm.org/D121488 to ensure all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. Both fir.xrebox and fir.xembox codegen is updated to enforce this constraint. Also upstream the "normalized lower bound" attribute that was added in fir-dev since embox codegen was upstreamed, it is conflicting with this patch otherwise. Differential Revision: https://reviews.llvm.org/D122419
2022-03-25 09:02:48 +01:00
const bool isaPointerOrAllocatable =
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
mlir::isa<fir::PointerType, fir::HeapType>(eleTy);
[flang][codegen] ensure descriptor lower bounds are LBOUND compliant Follow-up of https://reviews.llvm.org/D121488 to ensure all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. Both fir.xrebox and fir.xembox codegen is updated to enforce this constraint. Also upstream the "normalized lower bound" attribute that was added in fir-dev since embox codegen was upstreamed, it is conflicting with this patch otherwise. Differential Revision: https://reviews.llvm.org/D122419
2022-03-25 09:02:48 +01:00
// Lower bound is defaults to 1 for POINTER, ALLOCATABLE, and
// denormalized descriptors.
[flang] Fix bug in character casting. Add missing sext/trunc in code gen. This patch is part of the upstreaming effort from fir-dev branch. It also ensures all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D128047 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2022-06-17 16:09:32 +02:00
if (isaPointerOrAllocatable || !normalizedLowerBound(xbox))
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
lb = one;
[flang] Fix bug in character casting. Add missing sext/trunc in code gen. This patch is part of the upstreaming effort from fir-dev branch. It also ensures all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D128047 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2022-06-17 16:09:32 +02:00
// If there is a shifted origin, and no fir.slice, and this is not
// a normalized descriptor then use the value from the shift op as
// the lower bound.
if (hasShift && !(hasSlice || hasSubcomp || hasSubstr) &&
(isaPointerOrAllocatable || !normalizedLowerBound(xbox))) {
[flang] Support non-index shape/shift/slice for CG box operations. (#124625) That is another problem uncovered during hlfir.reshape inlining, where the shape bits could be any integer type. This patch adds explicit convertions to `index` type where needed.
2025-01-28 09:38:33 -08:00
lb = integerCast(loc, rewriter, i64Ty, operands[shiftOffset]);
[flang] Fix bug in character casting. Add missing sext/trunc in code gen. This patch is part of the upstreaming effort from fir-dev branch. It also ensures all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D128047 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2022-06-17 16:09:32 +02:00
auto extentIsEmpty = rewriter.create<mlir::LLVM::ICmpOp>(
loc, mlir::LLVM::ICmpPredicate::eq, extent, zero);
lb = rewriter.create<mlir::LLVM::SelectOp>(loc, extentIsEmpty, one,
lb);
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
}
dest = insertLowerBound(rewriter, loc, dest, descIdx, lb);
dest = insertExtent(rewriter, loc, dest, descIdx, extent);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// store step (scaled by shaped extent)
[flang] Fix bug in character casting. Add missing sext/trunc in code gen. This patch is part of the upstreaming effort from fir-dev branch. It also ensures all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D128047 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2022-06-17 16:09:32 +02:00
mlir::Value step = prevDimByteStride;
[flang] Support non-index shape/shift/slice for CG box operations. (#124625) That is another problem uncovered during hlfir.reshape inlining, where the shape bits could be any integer type. This patch adds explicit convertions to `index` type where needed.
2025-01-28 09:38:33 -08:00
if (hasSlice) {
mlir::Value sliceStep =
integerCast(loc, rewriter, i64Ty, operands[sliceOffset + 2]);
step =
rewriter.create<mlir::LLVM::MulOp>(loc, i64Ty, step, sliceStep);
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
dest = insertStride(rewriter, loc, dest, descIdx, step);
++descIdx;
}
// compute the stride and offset for the next natural dimension
[flang] Fix bug in character casting. Add missing sext/trunc in code gen. This patch is part of the upstreaming effort from fir-dev branch. It also ensures all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D128047 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2022-06-17 16:09:32 +02:00
prevDimByteStride = rewriter.create<mlir::LLVM::MulOp>(
loc, i64Ty, prevDimByteStride, outerExtent);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
if (constRows == 0)
prevPtrOff = rewriter.create<mlir::LLVM::MulOp>(loc, i64Ty, prevPtrOff,
outerExtent);
[flang] Fix fir.embox codegen with constant interior shape Fix https://github.com/flang-compiler/f18-llvm-project/issues/1416. The `constRows` variable was being decremented too soon, causing the last constant interior dimension extent being used to multiply the GEP offset. This lead to wrong address computation and caused segfaults. Note: also upstream fir.embox tests that can be upstreamed. Differential Revision: https://reviews.llvm.org/D123130
2022-04-05 17:26:53 +02:00
else
--constRows;
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// increment iterators
++shapeOffset;
if (hasShift)
++shiftOffset;
if (hasSlice)
sliceOffset += 3;
}
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::Value base = adaptor.getMemref();
[flang] Fix bug in character casting. Add missing sext/trunc in code gen. This patch is part of the upstreaming effort from fir-dev branch. It also ensures all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D128047 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2022-06-17 16:09:32 +02:00
if (hasSlice || hasSubcomp || hasSubstr) {
[flang] Merge GEPs in substring fir.embox codegen When computing the base addresses of an array slice to make a descriptor, codegen generated two LLVM GEPs. The first to compute the address of the base character element, and a second one to compute the substring base inside that element. The previous code did not care about getting the result of the first GEP right: it used the base array LLVM type as the result type. This used to work when opaque pointer were not enabled (the actual GEP result type was probably applied in some later pass). But with opaque pointers, the second GEP ends-up computing an offset of len*<LLVM array type> instead of len*<character width>. A previous attempt to fix the issue was done in D129079, but it does not cover the cases where the array slice contains subcomponents before the substring (e.g: array(:)%char_field(5:10)). This patch fix the issue by computing the actual GEP result type in codegen. There is also enough knowledge now so that a single GEP can be generated instead of two. Differential Revision: https://reviews.llvm.org/D129481
2022-07-12 09:26:16 +02:00
// Shift the base address.
llvm::SmallVector<mlir::Value> fieldIndices;
mlir/tblgen: use std::optional in generation This is part of an effort to migrate from llvm::Optional to std::optional. This patch changes the way mlir-tblgen generates .inc files, and modifies tests and documentation appropriately. It is a "no compromises" patch, and doesn't leave the user with an unpleasant mix of llvm::Optional and std::optional. A non-trivial change has been made to ControlFlowInterfaces to split one constructor into two, relating to a build failure on Windows. See also: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 Signed-off-by: Ramkumar Ramachandra <r@artagnon.com> Differential Revision: https://reviews.llvm.org/D138934
2022-12-14 11:39:19 +01:00
std::optional<mlir::Value> substringOffset;
[flang] Merge GEPs in substring fir.embox codegen When computing the base addresses of an array slice to make a descriptor, codegen generated two LLVM GEPs. The first to compute the address of the base character element, and a second one to compute the substring base inside that element. The previous code did not care about getting the result of the first GEP right: it used the base array LLVM type as the result type. This used to work when opaque pointer were not enabled (the actual GEP result type was probably applied in some later pass). But with opaque pointers, the second GEP ends-up computing an offset of len*<LLVM array type> instead of len*<character width>. A previous attempt to fix the issue was done in D129079, but it does not cover the cases where the array slice contains subcomponents before the substring (e.g: array(:)%char_field(5:10)). This patch fix the issue by computing the actual GEP result type in codegen. There is also enough knowledge now so that a single GEP can be generated instead of two. Differential Revision: https://reviews.llvm.org/D129481
2022-07-12 09:26:16 +02:00
if (hasSubcomp)
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
getSubcomponentIndices(xbox, xbox.getMemref(), operands, fieldIndices);
[flang] Fix bug in character casting. Add missing sext/trunc in code gen. This patch is part of the upstreaming effort from fir-dev branch. It also ensures all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D128047 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2022-06-17 16:09:32 +02:00
if (hasSubstr)
[flang][NFC] rename fircg op operand index accessors (#100584) fircg operations have xxxOffset members to give the operand index of operand xxx. This is a bit weird when looking at usage (e.g. `arrayCoor.shiftOffset` reads like it is shifting some offset). Rename them to getXxxOperandIndex.
2024-07-25 18:02:03 +02:00
substringOffset = operands[xbox.getSubstrOperandIndex()];
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::Type llvmBaseType =
convertType(fir::unwrapRefType(xbox.getMemref().getType()));
base = genBoxOffsetGep(rewriter, loc, base, llvmBaseType, ptrOffset,
cstInteriorIndices, fieldIndices, substringOffset);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
dest = insertBaseAddress(rewriter, loc, dest, base);
[flang] Moving common polymorphic code into utility files Differential revision: https://reviews.llvm.org/D145530
2023-03-07 16:09:23 -08:00
if (fir::isDerivedTypeWithLenParams(boxTy))
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
TODO(loc, "fir.embox codegen of derived with length parameters");
[flang][cuda] Allocate descriptor in managed memory when emboxing device memory (#120485) When emboxing memory that comes from CUFMemAlloc, we need to allocate the descriptor in manage memory as it might be passed to a kernel.
2024-12-18 18:20:45 -08:00
mlir::Value result = placeInMemoryIfNotGlobalInit(
[flang][cuda] Allocate descriptor in managed memory when memref is a block argument (#123829)
2025-01-21 17:20:46 -08:00
rewriter, loc, boxTy, dest,
isDeviceAllocation(xbox.getMemref(), adaptor.getMemref()));
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
rewriter.replaceOp(xbox, result);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
[flang][codegen] ensure descriptor lower bounds are LBOUND compliant Follow-up of https://reviews.llvm.org/D121488 to ensure all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. Both fir.xrebox and fir.xembox codegen is updated to enforce this constraint. Also upstream the "normalized lower bound" attribute that was added in fir-dev since embox codegen was upstreamed, it is conflicting with this patch otherwise. Differential Revision: https://reviews.llvm.org/D122419
2022-03-25 09:02:48 +01:00
/// Return true if `xbox` has a normalized lower bounds attribute. A box value
/// that is neither a POINTER nor an ALLOCATABLE should be normalized to a
/// zero origin lower bound for interoperability with BIND(C).
inline static bool normalizedLowerBound(fir::cg::XEmboxOp xbox) {
return xbox->hasAttr(fir::getNormalizedLowerBoundAttrName());
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
};
/// Create a new box given a box reference.
struct XReboxOpConversion : public EmboxCommonConversion<fir::cg::XReboxOp> {
using EmboxCommonConversion::EmboxCommonConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::cg::XReboxOp rebox, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
mlir::Location loc = rebox.getLoc();
mlir::Type idxTy = lowerTy().indexType();
mlir::Value loweredBox = adaptor.getOperands()[0];
mlir::ValueRange operands = adaptor.getOperands();
[flang] Allow and use fir.rebox in fir.global The current lowering of initial target in fir.global is relying on how fir.box are created: instead of using a fir.rebox to add the POINTER attribute to the created descriptor, it is looking for a fir.embox defining operation and creating a copy of it with a different result types. The rational for doing so was that fir.rebox codegen was not possible inside fir.global because it expects to manipulate the input fir.box in memory, while objects cannot be manipulated in memory inside a fir.global region that must be constant foldable. But this approach has two problems: - it won't work with hlfir where fir.box may be created by more operations than fir.embox (e.g. hlfir.delcare or hlfir.designate). In general, looking for a precise defining op for a value is fragile. - manually copying and modifying an operation is risky: it is easy to forget copying some default operands (that could be added later). This patch modifies the helpers to get descriptor fields so that they can both operate on fir.box lowered in memory or in an llvm.struct value. This enables the usage of fir.rebox in fir.global op. The fallout in FIR tests is caused by the usage of constant index when creating GEP (because extractOp requires constant indices). MLIR builder uses i32 bit constant indices when non mlir::Value indices are passed to the MLIR GEP op builder. Previously, an 64 nist mlir constant value was created and passed to the GEP builder. In this case, the builder respect the value type when later generating the GEP. Given this changes impact the "dimension" index that can, per Fortran requirement, not be greated than 15, using a 32 bit index is just fine and actually simplify the MLIR LLVM IR generation. The fallout in lowering tests is caused by the introduction of the fir.rebox everytime an initial target is created. Differential Revision: https://reviews.llvm.org/D141136
2023-01-10 09:01:38 +01:00
// Inside a fir.global, the input box was produced as an llvm.struct<>
// because objects cannot be handled in memory inside a fir.global body that
// must be constant foldable. However, the type translation are not
// contextual, so the fir.box<T> type of the operation that produced the
// fir.box was translated to an llvm.ptr<llvm.struct<>> and the MLIR pass
// manager inserted a builtin.unrealized_conversion_cast that was inserted
// and needs to be removed here.
if (isInGlobalOp(rewriter))
if (auto unrealizedCast =
loweredBox.getDefiningOp<mlir::UnrealizedConversionCastOp>())
loweredBox = unrealizedCast.getInputs()[0];
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
TypePair inputBoxTyPair = getBoxTypePair(rebox.getBox().getType());
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// Create new descriptor and fill its non-shape related data.
llvm::SmallVector<mlir::Value, 2> lenParams;
mlir::Type inputEleTy = getInputEleTy(rebox);
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (auto charTy = mlir::dyn_cast<fir::CharacterType>(inputEleTy)) {
[flang] Support CHARACTER(4) pointer targets fir.rebox is emitting an llvm.sdiv to compute the character length given the byte size from the input descriptor. Inside a fir.global, this is not needed given the target length must be accessible via the type, and it caused MLIR to fail LLVM IR code generation (and crash). Use the input type length when available instead. Reviewed By: PeteSteinfeld, vzakhari Differential Revision: https://reviews.llvm.org/D154072
2023-06-29 18:36:05 +02:00
if (charTy.hasConstantLen()) {
mlir::Value len =
genConstantIndex(loc, idxTy, rewriter, charTy.getLen());
lenParams.emplace_back(len);
} else {
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::Value len = getElementSizeFromBox(loc, idxTy, inputBoxTyPair,
loweredBox, rewriter);
[flang] Support CHARACTER(4) pointer targets fir.rebox is emitting an llvm.sdiv to compute the character length given the byte size from the input descriptor. Inside a fir.global, this is not needed given the target length must be accessible via the type, and it caused MLIR to fail LLVM IR code generation (and crash). Use the input type length when available instead. Reviewed By: PeteSteinfeld, vzakhari Differential Revision: https://reviews.llvm.org/D154072
2023-06-29 18:36:05 +02:00
if (charTy.getFKind() != 1) {
assert(!isInGlobalOp(rewriter) &&
"character target in global op must have constant length");
mlir::Value width =
genConstantIndex(loc, idxTy, rewriter, charTy.getFKind());
len = rewriter.create<mlir::LLVM::SDivOp>(loc, idxTy, len, width);
}
lenParams.emplace_back(len);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
} else if (auto recTy = mlir::dyn_cast<fir::RecordType>(inputEleTy)) {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
if (recTy.getNumLenParams() != 0)
TODO(loc, "reboxing descriptor of derived type with length parameters");
}
[flang] Carry dynamic type in fir.rebox code generation Load the pointer of the dynamic type descriptor from the original box and update the destination descriptor with this pointer. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D136618
2022-10-24 20:42:31 +02:00
// Rebox on polymorphic entities needs to carry over the dynamic type.
mlir::Value typeDescAddr;
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (mlir::isa<fir::ClassType>(inputBoxTyPair.fir) &&
mlir::isa<fir::ClassType>(rebox.getType()))
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
typeDescAddr =
loadTypeDescAddress(loc, inputBoxTyPair, loweredBox, rewriter);
[flang] Carry dynamic type in fir.rebox code generation Load the pointer of the dynamic type descriptor from the original box and update the destination descriptor with this pointer. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D136618
2022-10-24 20:42:31 +02:00
[flang] Adapt descriptor codegen to support unlimited polymorphic entities Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-24 20:33:15 +01:00
auto [boxTy, dest, eleSize] =
consDescriptorPrefix(rebox, loweredBox, rewriter, rebox.getOutRank(),
[flang] Fixed substr access in embox/rebox CodeGen. The code was using the original operand of the operation, while it should have been using the remapped operands via the adaptor. Differential Revision: https://reviews.llvm.org/D148587
2023-04-17 17:06:14 -07:00
adaptor.getSubstr(), lenParams, typeDescAddr);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// Read input extents, strides, and base address
llvm::SmallVector<mlir::Value> inputExtents;
llvm::SmallVector<mlir::Value> inputStrides;
const unsigned inputRank = rebox.getRank();
[flang] Allow and use fir.rebox in fir.global The current lowering of initial target in fir.global is relying on how fir.box are created: instead of using a fir.rebox to add the POINTER attribute to the created descriptor, it is looking for a fir.embox defining operation and creating a copy of it with a different result types. The rational for doing so was that fir.rebox codegen was not possible inside fir.global because it expects to manipulate the input fir.box in memory, while objects cannot be manipulated in memory inside a fir.global region that must be constant foldable. But this approach has two problems: - it won't work with hlfir where fir.box may be created by more operations than fir.embox (e.g. hlfir.delcare or hlfir.designate). In general, looking for a precise defining op for a value is fragile. - manually copying and modifying an operation is risky: it is easy to forget copying some default operands (that could be added later). This patch modifies the helpers to get descriptor fields so that they can both operate on fir.box lowered in memory or in an llvm.struct value. This enables the usage of fir.rebox in fir.global op. The fallout in FIR tests is caused by the usage of constant index when creating GEP (because extractOp requires constant indices). MLIR builder uses i32 bit constant indices when non mlir::Value indices are passed to the MLIR GEP op builder. Previously, an 64 nist mlir constant value was created and passed to the GEP builder. In this case, the builder respect the value type when later generating the GEP. Given this changes impact the "dimension" index that can, per Fortran requirement, not be greated than 15, using a 32 bit index is just fine and actually simplify the MLIR LLVM IR generation. The fallout in lowering tests is caused by the introduction of the fir.rebox everytime an initial target is created. Differential Revision: https://reviews.llvm.org/D141136
2023-01-10 09:01:38 +01:00
for (unsigned dim = 0; dim < inputRank; ++dim) {
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
llvm::SmallVector<mlir::Value, 3> dimInfo =
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
getDimsFromBox(loc, {idxTy, idxTy, idxTy}, inputBoxTyPair, loweredBox,
dim, rewriter);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
inputExtents.emplace_back(dimInfo[1]);
inputStrides.emplace_back(dimInfo[2]);
}
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::Value baseAddr =
getBaseAddrFromBox(loc, inputBoxTyPair, loweredBox, rewriter);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
if (!rebox.getSlice().empty() || !rebox.getSubcomponent().empty())
[flang][cuda] Allocate descriptor in managed memory on rebox block argument (#123971) Another case where the descriptor must be allocated with the CUF runtime and not a simple alloca instruction.
2025-01-22 10:04:39 -08:00
return sliceBox(rebox, adaptor, boxTy, dest, baseAddr, inputExtents,
inputStrides, operands, rewriter);
return reshapeBox(rebox, adaptor, boxTy, dest, baseAddr, inputExtents,
inputStrides, operands, rewriter);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
private:
/// Write resulting shape and base address in descriptor, and replace rebox
/// op.
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[flang][cuda] Allocate descriptor in managed memory on rebox block argument (#123971) Another case where the descriptor must be allocated with the CUF runtime and not a simple alloca instruction.
2025-01-22 10:04:39 -08:00
finalizeRebox(fir::cg::XReboxOp rebox, OpAdaptor adaptor,
mlir::Type destBoxTy, mlir::Value dest, mlir::Value base,
mlir::ValueRange lbounds, mlir::ValueRange extents,
mlir::ValueRange strides,
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::ConversionPatternRewriter &rewriter) const {
mlir::Location loc = rebox.getLoc();
[flang][codegen] ensure descriptor lower bounds are LBOUND compliant Follow-up of https://reviews.llvm.org/D121488 to ensure all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. Both fir.xrebox and fir.xembox codegen is updated to enforce this constraint. Also upstream the "normalized lower bound" attribute that was added in fir-dev since embox codegen was upstreamed, it is conflicting with this patch otherwise. Differential Revision: https://reviews.llvm.org/D122419
2022-03-25 09:02:48 +01:00
mlir::Value zero =
genConstantIndex(loc, lowerTy().indexType(), rewriter, 0);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::Value one = genConstantIndex(loc, lowerTy().indexType(), rewriter, 1);
for (auto iter : llvm::enumerate(llvm::zip(extents, strides))) {
[flang][codegen] ensure descriptor lower bounds are LBOUND compliant Follow-up of https://reviews.llvm.org/D121488 to ensure all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. Both fir.xrebox and fir.xembox codegen is updated to enforce this constraint. Also upstream the "normalized lower bound" attribute that was added in fir-dev since embox codegen was upstreamed, it is conflicting with this patch otherwise. Differential Revision: https://reviews.llvm.org/D122419
2022-03-25 09:02:48 +01:00
mlir::Value extent = std::get<0>(iter.value());
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
unsigned dim = iter.index();
[flang][codegen] ensure descriptor lower bounds are LBOUND compliant Follow-up of https://reviews.llvm.org/D121488 to ensure all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. Both fir.xrebox and fir.xembox codegen is updated to enforce this constraint. Also upstream the "normalized lower bound" attribute that was added in fir-dev since embox codegen was upstreamed, it is conflicting with this patch otherwise. Differential Revision: https://reviews.llvm.org/D122419
2022-03-25 09:02:48 +01:00
mlir::Value lb = one;
if (!lbounds.empty()) {
Reland [flang] In AllocMemOp lowering, convert types for calling malloc on 32-bit (#130386) Previous PR: https://github.com/llvm/llvm-project/pull/129308 Changes: * The alloc-32.fir test is now marked as requiring the X86 target. * Drive-by fixes uncovered when fixing tests involving malloc
2025-03-11 02:01:57 +00:00
lb = integerCast(loc, rewriter, lowerTy().indexType(), lbounds[dim]);
[flang][codegen] ensure descriptor lower bounds are LBOUND compliant Follow-up of https://reviews.llvm.org/D121488 to ensure all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. Both fir.xrebox and fir.xembox codegen is updated to enforce this constraint. Also upstream the "normalized lower bound" attribute that was added in fir-dev since embox codegen was upstreamed, it is conflicting with this patch otherwise. Differential Revision: https://reviews.llvm.org/D122419
2022-03-25 09:02:48 +01:00
auto extentIsEmpty = rewriter.create<mlir::LLVM::ICmpOp>(
loc, mlir::LLVM::ICmpPredicate::eq, extent, zero);
lb = rewriter.create<mlir::LLVM::SelectOp>(loc, extentIsEmpty, one, lb);
};
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
dest = insertLowerBound(rewriter, loc, dest, dim, lb);
[flang][codegen] ensure descriptor lower bounds are LBOUND compliant Follow-up of https://reviews.llvm.org/D121488 to ensure all descriptors created inline complies with LBOUND requirement that the lower bound is `1` when the related dimension extent is zero. Both fir.xrebox and fir.xembox codegen is updated to enforce this constraint. Also upstream the "normalized lower bound" attribute that was added in fir-dev since embox codegen was upstreamed, it is conflicting with this patch otherwise. Differential Revision: https://reviews.llvm.org/D122419
2022-03-25 09:02:48 +01:00
dest = insertExtent(rewriter, loc, dest, dim, extent);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
dest = insertStride(rewriter, loc, dest, dim, std::get<1>(iter.value()));
}
dest = insertBaseAddress(rewriter, loc, dest, base);
[flang][cuda] Allocate descriptor in managed memory when memref is a block argument (#123829)
2025-01-21 17:20:46 -08:00
mlir::Value result = placeInMemoryIfNotGlobalInit(
rewriter, rebox.getLoc(), destBoxTy, dest,
[flang][cuda] Allocate descriptor in managed memory on rebox block argument (#123971) Another case where the descriptor must be allocated with the CUF runtime and not a simple alloca instruction.
2025-01-22 10:04:39 -08:00
isDeviceAllocation(rebox.getBox(), adaptor.getBox()));
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
rewriter.replaceOp(rebox, result);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
// Apply slice given the base address, extents and strides of the input box.
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[flang][cuda] Allocate descriptor in managed memory on rebox block argument (#123971) Another case where the descriptor must be allocated with the CUF runtime and not a simple alloca instruction.
2025-01-22 10:04:39 -08:00
sliceBox(fir::cg::XReboxOp rebox, OpAdaptor adaptor, mlir::Type destBoxTy,
mlir::Value dest, mlir::Value base, mlir::ValueRange inputExtents,
[flang] Generate TBAA information. This is initial version of TBAA information generation for Flang generated IR. The desired behavior is that TBAA type descriptors are generated for FIR types during FIR to LLVM types conversion, and then TBAA access tags are attached to memory accessing operations when they are converted to LLVM IR dialect. In the initial version the type conversion is not producing TBAA type descriptors, and all memory accesses are just partitioned into two sets of box and non-box accesses, which can never alias. The TBAA generation is enabled by default at >O0 optimization levels. TBAA generation may also be enabled via `apply-tbaa` option of `fir-to-llvm-ir` conversion pass. `-mllvm -disable-tbaa` engineering option allows disabling TBAA generation to override Flang's default (e.g. when -O1 is used). SPEC CPU2006/437.leslie3d speeds up by more than 2x on Icelake. Reviewed By: jeanPerier, clementval Differential Revision: https://reviews.llvm.org/D141820
2023-01-17 09:08:43 -08:00
mlir::ValueRange inputStrides, mlir::ValueRange operands,
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::ConversionPatternRewriter &rewriter) const {
mlir::Location loc = rebox.getLoc();
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::Type byteTy = ::getI8Type(rebox.getContext());
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::Type idxTy = lowerTy().indexType();
mlir::Value zero = genConstantIndex(loc, idxTy, rewriter, 0);
// Apply subcomponent and substring shift on base address.
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
if (!rebox.getSubcomponent().empty() || !rebox.getSubstr().empty()) {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// Cast to inputEleTy* so that a GEP can be used.
mlir::Type inputEleTy = getInputEleTy(rebox);
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::Type llvmBaseObjectType = convertType(inputEleTy);
[flang] Merge GEPs in substring fir.embox codegen When computing the base addresses of an array slice to make a descriptor, codegen generated two LLVM GEPs. The first to compute the address of the base character element, and a second one to compute the substring base inside that element. The previous code did not care about getting the result of the first GEP right: it used the base array LLVM type as the result type. This used to work when opaque pointer were not enabled (the actual GEP result type was probably applied in some later pass). But with opaque pointers, the second GEP ends-up computing an offset of len*<LLVM array type> instead of len*<character width>. A previous attempt to fix the issue was done in D129079, but it does not cover the cases where the array slice contains subcomponents before the substring (e.g: array(:)%char_field(5:10)). This patch fix the issue by computing the actual GEP result type in codegen. There is also enough knowledge now so that a single GEP can be generated instead of two. Differential Revision: https://reviews.llvm.org/D129481
2022-07-12 09:26:16 +02:00
llvm::SmallVector<mlir::Value> fieldIndices;
mlir/tblgen: use std::optional in generation This is part of an effort to migrate from llvm::Optional to std::optional. This patch changes the way mlir-tblgen generates .inc files, and modifies tests and documentation appropriately. It is a "no compromises" patch, and doesn't leave the user with an unpleasant mix of llvm::Optional and std::optional. A non-trivial change has been made to ControlFlowInterfaces to split one constructor into two, relating to a build failure on Windows. See also: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 Signed-off-by: Ramkumar Ramachandra <r@artagnon.com> Differential Revision: https://reviews.llvm.org/D138934
2022-12-14 11:39:19 +01:00
std::optional<mlir::Value> substringOffset;
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
if (!rebox.getSubcomponent().empty())
getSubcomponentIndices(rebox, rebox.getBox(), operands, fieldIndices);
if (!rebox.getSubstr().empty())
[flang][NFC] rename fircg op operand index accessors (#100584) fircg operations have xxxOffset members to give the operand index of operand xxx. This is a bit weird when looking at usage (e.g. `arrayCoor.shiftOffset` reads like it is shifting some offset). Rename them to getXxxOperandIndex.
2024-07-25 18:02:03 +02:00
substringOffset = operands[rebox.getSubstrOperandIndex()];
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
base = genBoxOffsetGep(rewriter, loc, base, llvmBaseObjectType, zero,
[flang] Use std::nullopt instead of None (NFC) This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-03 12:14:21 -08:00
/*cstInteriorIndices=*/std::nullopt, fieldIndices,
[flang] Merge GEPs in substring fir.embox codegen When computing the base addresses of an array slice to make a descriptor, codegen generated two LLVM GEPs. The first to compute the address of the base character element, and a second one to compute the substring base inside that element. The previous code did not care about getting the result of the first GEP right: it used the base array LLVM type as the result type. This used to work when opaque pointer were not enabled (the actual GEP result type was probably applied in some later pass). But with opaque pointers, the second GEP ends-up computing an offset of len*<LLVM array type> instead of len*<character width>. A previous attempt to fix the issue was done in D129079, but it does not cover the cases where the array slice contains subcomponents before the substring (e.g: array(:)%char_field(5:10)). This patch fix the issue by computing the actual GEP result type in codegen. There is also enough knowledge now so that a single GEP can be generated instead of two. Differential Revision: https://reviews.llvm.org/D129481
2022-07-12 09:26:16 +02:00
substringOffset);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
if (rebox.getSlice().empty())
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// The array section is of the form array[%component][substring], keep
// the input array extents and strides.
[flang][cuda] Allocate descriptor in managed memory on rebox block argument (#123971) Another case where the descriptor must be allocated with the CUF runtime and not a simple alloca instruction.
2025-01-22 10:04:39 -08:00
return finalizeRebox(rebox, adaptor, destBoxTy, dest, base,
[flang] Generate TBAA information. This is initial version of TBAA information generation for Flang generated IR. The desired behavior is that TBAA type descriptors are generated for FIR types during FIR to LLVM types conversion, and then TBAA access tags are attached to memory accessing operations when they are converted to LLVM IR dialect. In the initial version the type conversion is not producing TBAA type descriptors, and all memory accesses are just partitioned into two sets of box and non-box accesses, which can never alias. The TBAA generation is enabled by default at >O0 optimization levels. TBAA generation may also be enabled via `apply-tbaa` option of `fir-to-llvm-ir` conversion pass. `-mllvm -disable-tbaa` engineering option allows disabling TBAA generation to override Flang's default (e.g. when -O1 is used). SPEC CPU2006/437.leslie3d speeds up by more than 2x on Icelake. Reviewed By: jeanPerier, clementval Differential Revision: https://reviews.llvm.org/D141820
2023-01-17 09:08:43 -08:00
/*lbounds*/ std::nullopt, inputExtents, inputStrides,
rewriter);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// The slice is of the form array(i:j:k)[%component]. Compute new extents
// and strides.
llvm::SmallVector<mlir::Value> slicedExtents;
llvm::SmallVector<mlir::Value> slicedStrides;
mlir::Value one = genConstantIndex(loc, idxTy, rewriter, 1);
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
const bool sliceHasOrigins = !rebox.getShift().empty();
[flang][NFC] rename fircg op operand index accessors (#100584) fircg operations have xxxOffset members to give the operand index of operand xxx. This is a bit weird when looking at usage (e.g. `arrayCoor.shiftOffset` reads like it is shifting some offset). Rename them to getXxxOperandIndex.
2024-07-25 18:02:03 +02:00
unsigned sliceOps = rebox.getSliceOperandIndex();
unsigned shiftOps = rebox.getShiftOperandIndex();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
auto strideOps = inputStrides.begin();
const unsigned inputRank = inputStrides.size();
for (unsigned i = 0; i < inputRank;
++i, ++strideOps, ++shiftOps, sliceOps += 3) {
mlir::Value sliceLb =
integerCast(loc, rewriter, idxTy, operands[sliceOps]);
mlir::Value inputStride = *strideOps; // already idxTy
// Apply origin shift: base += (lb-shift)*input_stride
mlir::Value sliceOrigin =
sliceHasOrigins
? integerCast(loc, rewriter, idxTy, operands[shiftOps])
: one;
mlir::Value diff =
rewriter.create<mlir::LLVM::SubOp>(loc, idxTy, sliceLb, sliceOrigin);
mlir::Value offset =
rewriter.create<mlir::LLVM::MulOp>(loc, idxTy, diff, inputStride);
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
// Strides from the fir.box are in bytes.
base = genGEP(loc, byteTy, rewriter, base, offset);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// Apply upper bound and step if this is a triplet. Otherwise, the
// dimension is dropped and no extents/strides are computed.
mlir::Value upper = operands[sliceOps + 1];
const bool isTripletSlice =
!mlir::isa_and_nonnull<mlir::LLVM::UndefOp>(upper.getDefiningOp());
if (isTripletSlice) {
mlir::Value step =
integerCast(loc, rewriter, idxTy, operands[sliceOps + 2]);
// extent = ub-lb+step/step
mlir::Value sliceUb = integerCast(loc, rewriter, idxTy, upper);
mlir::Value extent = computeTripletExtent(rewriter, loc, sliceLb,
sliceUb, step, zero, idxTy);
slicedExtents.emplace_back(extent);
// stride = step*input_stride
mlir::Value stride =
rewriter.create<mlir::LLVM::MulOp>(loc, idxTy, step, inputStride);
slicedStrides.emplace_back(stride);
}
}
[flang][cuda] Allocate descriptor in managed memory on rebox block argument (#123971) Another case where the descriptor must be allocated with the CUF runtime and not a simple alloca instruction.
2025-01-22 10:04:39 -08:00
return finalizeRebox(rebox, adaptor, destBoxTy, dest, base,
/*lbounds*/ std::nullopt, slicedExtents, slicedStrides,
rewriter);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
/// Apply a new shape to the data described by a box given the base address,
/// extents and strides of the box.
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[flang][cuda] Allocate descriptor in managed memory on rebox block argument (#123971) Another case where the descriptor must be allocated with the CUF runtime and not a simple alloca instruction.
2025-01-22 10:04:39 -08:00
reshapeBox(fir::cg::XReboxOp rebox, OpAdaptor adaptor, mlir::Type destBoxTy,
mlir::Value dest, mlir::Value base, mlir::ValueRange inputExtents,
[flang] Generate TBAA information. This is initial version of TBAA information generation for Flang generated IR. The desired behavior is that TBAA type descriptors are generated for FIR types during FIR to LLVM types conversion, and then TBAA access tags are attached to memory accessing operations when they are converted to LLVM IR dialect. In the initial version the type conversion is not producing TBAA type descriptors, and all memory accesses are just partitioned into two sets of box and non-box accesses, which can never alias. The TBAA generation is enabled by default at >O0 optimization levels. TBAA generation may also be enabled via `apply-tbaa` option of `fir-to-llvm-ir` conversion pass. `-mllvm -disable-tbaa` engineering option allows disabling TBAA generation to override Flang's default (e.g. when -O1 is used). SPEC CPU2006/437.leslie3d speeds up by more than 2x on Icelake. Reviewed By: jeanPerier, clementval Differential Revision: https://reviews.llvm.org/D141820
2023-01-17 09:08:43 -08:00
mlir::ValueRange inputStrides, mlir::ValueRange operands,
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::ConversionPatternRewriter &rewriter) const {
[flang][NFC] rename fircg op operand index accessors (#100584) fircg operations have xxxOffset members to give the operand index of operand xxx. This is a bit weird when looking at usage (e.g. `arrayCoor.shiftOffset` reads like it is shifting some offset). Rename them to getXxxOperandIndex.
2024-07-25 18:02:03 +02:00
mlir::ValueRange reboxShifts{
operands.begin() + rebox.getShiftOperandIndex(),
operands.begin() + rebox.getShiftOperandIndex() +
rebox.getShift().size()};
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
if (rebox.getShape().empty()) {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// Only setting new lower bounds.
[flang][cuda] Allocate descriptor in managed memory on rebox block argument (#123971) Another case where the descriptor must be allocated with the CUF runtime and not a simple alloca instruction.
2025-01-22 10:04:39 -08:00
return finalizeRebox(rebox, adaptor, destBoxTy, dest, base, reboxShifts,
[flang] Generate TBAA information. This is initial version of TBAA information generation for Flang generated IR. The desired behavior is that TBAA type descriptors are generated for FIR types during FIR to LLVM types conversion, and then TBAA access tags are attached to memory accessing operations when they are converted to LLVM IR dialect. In the initial version the type conversion is not producing TBAA type descriptors, and all memory accesses are just partitioned into two sets of box and non-box accesses, which can never alias. The TBAA generation is enabled by default at >O0 optimization levels. TBAA generation may also be enabled via `apply-tbaa` option of `fir-to-llvm-ir` conversion pass. `-mllvm -disable-tbaa` engineering option allows disabling TBAA generation to override Flang's default (e.g. when -O1 is used). SPEC CPU2006/437.leslie3d speeds up by more than 2x on Icelake. Reviewed By: jeanPerier, clementval Differential Revision: https://reviews.llvm.org/D141820
2023-01-17 09:08:43 -08:00
inputExtents, inputStrides, rewriter);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
mlir::Location loc = rebox.getLoc();
llvm::SmallVector<mlir::Value> newStrides;
llvm::SmallVector<mlir::Value> newExtents;
mlir::Type idxTy = lowerTy().indexType();
// First stride from input box is kept. The rest is assumed contiguous
// (it is not possible to reshape otherwise). If the input is scalar,
// which may be OK if all new extents are ones, the stride does not
// matter, use one.
mlir::Value stride = inputStrides.empty()
? genConstantIndex(loc, idxTy, rewriter, 1)
: inputStrides[0];
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
for (unsigned i = 0; i < rebox.getShape().size(); ++i) {
[flang][NFC] rename fircg op operand index accessors (#100584) fircg operations have xxxOffset members to give the operand index of operand xxx. This is a bit weird when looking at usage (e.g. `arrayCoor.shiftOffset` reads like it is shifting some offset). Rename them to getXxxOperandIndex.
2024-07-25 18:02:03 +02:00
mlir::Value rawExtent = operands[rebox.getShapeOperandIndex() + i];
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::Value extent = integerCast(loc, rewriter, idxTy, rawExtent);
newExtents.emplace_back(extent);
newStrides.emplace_back(stride);
// nextStride = extent * stride;
stride = rewriter.create<mlir::LLVM::MulOp>(loc, idxTy, extent, stride);
}
[flang][cuda] Allocate descriptor in managed memory on rebox block argument (#123971) Another case where the descriptor must be allocated with the CUF runtime and not a simple alloca instruction.
2025-01-22 10:04:39 -08:00
return finalizeRebox(rebox, adaptor, destBoxTy, dest, base, reboxShifts,
newExtents, newStrides, rewriter);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
/// Return scalar element type of the input box.
static mlir::Type getInputEleTy(fir::cg::XReboxOp rebox) {
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
auto ty = fir::dyn_cast_ptrOrBoxEleTy(rebox.getBox().getType());
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (auto seqTy = mlir::dyn_cast<fir::SequenceType>(ty))
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
return seqTy.getEleTy();
return ty;
}
};
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// Lower `fir.emboxproc` operation. Creates a procedure box.
/// TODO: Part of supporting Fortran 2003 procedure pointers.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct EmboxProcOpConversion : public fir::FIROpConversion<fir::EmboxProcOp> {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
using FIROpConversion::FIROpConversion;
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::EmboxProcOp emboxproc, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
TODO(emboxproc.getLoc(), "fir.emboxproc codegen");
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::failure();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
};
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// Code shared between insert_value and extract_value Ops.
struct ValueOpCommon {
// Translate the arguments pertaining to any multidimensional array to
// row-major order for LLVM-IR.
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
static void toRowMajor(llvm::SmallVectorImpl<int64_t> &indices,
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::Type ty) {
assert(ty && "type is null");
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
const auto end = indices.size();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
for (std::remove_const_t<decltype(end)> i = 0; i < end; ++i) {
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (auto seq = mlir::dyn_cast<mlir::LLVM::LLVMArrayType>(ty)) {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
const auto dim = getDimension(seq);
if (dim > 1) {
auto ub = std::min(i + dim, end);
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
std::reverse(indices.begin() + i, indices.begin() + ub);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
i += dim - 1;
}
ty = getArrayElementType(seq);
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
} else if (auto st = mlir::dyn_cast<mlir::LLVM::LLVMStructType>(ty)) {
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
ty = st.getBody()[indices[i]];
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
} else {
llvm_unreachable("index into invalid type");
}
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
static llvm::SmallVector<int64_t>
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
collectIndices(mlir::ConversionPatternRewriter &rewriter,
mlir::ArrayAttr arrAttr) {
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
llvm::SmallVector<int64_t> indices;
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
for (auto i = arrAttr.begin(), e = arrAttr.end(); i != e; ++i) {
[flang] Use `isa/dyn_cast/cast/...` free functions. (#90432) The corresponding member functions are deprecated.
2024-04-29 09:16:22 +02:00
if (auto intAttr = mlir::dyn_cast<mlir::IntegerAttr>(*i)) {
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
indices.push_back(intAttr.getInt());
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
} else {
[flang] Use `isa/dyn_cast/cast/...` free functions. (#90432) The corresponding member functions are deprecated.
2024-04-29 09:16:22 +02:00
auto fieldName = mlir::cast<mlir::StringAttr>(*i).getValue();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
++i;
[flang] Use `isa/dyn_cast/cast/...` free functions. (#90432) The corresponding member functions are deprecated.
2024-04-29 09:16:22 +02:00
auto ty = mlir::cast<mlir::TypeAttr>(*i).getValue();
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
auto index = mlir::cast<fir::RecordType>(ty).getFieldIndex(fieldName);
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
indices.push_back(index);
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
}
}
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
return indices;
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
private:
static mlir::Type getArrayElementType(mlir::LLVM::LLVMArrayType ty) {
auto eleTy = ty.getElementType();
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
while (auto arrTy = mlir::dyn_cast<mlir::LLVM::LLVMArrayType>(eleTy))
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
eleTy = arrTy.getElementType();
return eleTy;
}
};
namespace {
/// Extract a subobject value from an ssa-value of aggregate type
struct ExtractValueOpConversion
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
: public fir::FIROpAndTypeConversion<fir::ExtractValueOp>,
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
public ValueOpCommon {
using FIROpAndTypeConversion::FIROpAndTypeConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
doRewrite(fir::ExtractValueOp extractVal, mlir::Type ty, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
[flang] Make code more homogenous in CodeGen This patch just make the code more similar in each conversion. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D129071
2022-07-04 21:16:13 +02:00
mlir::ValueRange operands = adaptor.getOperands();
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
auto indices = collectIndices(rewriter, extractVal.getCoor());
toRowMajor(indices, operands[0].getType());
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
rewriter.replaceOpWithNewOp<mlir::LLVM::ExtractValueOp>(
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
extractVal, operands[0], indices);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[fir] Add fircg.ext_embox conversion Convert a fircg.ext_embox operation to LLVM IR dialect. A fircg.ext_embox is converted to a sequence of operation that create, allocate if needed, and populate a descriptor. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D114148 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-03 11:44:47 +01:00
}
};
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// InsertValue is the generalized instruction for the composition of new
/// aggregate type values.
struct InsertValueOpConversion
[flang] Remove materialization workaround in type converter (#98743) This change is in preparation of #97903, which adds extra checks for materializations: it is now enforced that they produce an SSA value of the correct type, so the current workaround no longer works. The original workaround avoided target materializations by directly returning the to-be-converted SSA value from the materialization callback. This can be avoided by initializing the lowering patterns that insert the materializations without a type converter. For `cg::XEmboxOp`, the existing workaround that skips `unrealized_conversion_cast` ops is still in place. Also remove the lowering pattern for `unrealized_conversion_cast`. This pattern has no effect because `unrealized_conversion_cast` ops that are inserted by the dialect conversion framework are never matched by the pattern driver.
2024-07-15 16:07:48 +02:00
: public mlir::OpConversionPattern<fir::InsertValueOp>,
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
public ValueOpCommon {
[flang] Remove materialization workaround in type converter (#98743) This change is in preparation of #97903, which adds extra checks for materializations: it is now enforced that they produce an SSA value of the correct type, so the current workaround no longer works. The original workaround avoided target materializations by directly returning the to-be-converted SSA value from the materialization callback. This can be avoided by initializing the lowering patterns that insert the materializations without a type converter. For `cg::XEmboxOp`, the existing workaround that skips `unrealized_conversion_cast` ops is still in place. Also remove the lowering pattern for `unrealized_conversion_cast`. This pattern has no effect because `unrealized_conversion_cast` ops that are inserted by the dialect conversion framework are never matched by the pattern driver.
2024-07-15 16:07:48 +02:00
using OpConversionPattern::OpConversionPattern;
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[flang] Remove materialization workaround in type converter (#98743) This change is in preparation of #97903, which adds extra checks for materializations: it is now enforced that they produce an SSA value of the correct type, so the current workaround no longer works. The original workaround avoided target materializations by directly returning the to-be-converted SSA value from the materialization callback. This can be avoided by initializing the lowering patterns that insert the materializations without a type converter. For `cg::XEmboxOp`, the existing workaround that skips `unrealized_conversion_cast` ops is still in place. Also remove the lowering pattern for `unrealized_conversion_cast`. This pattern has no effect because `unrealized_conversion_cast` ops that are inserted by the dialect conversion framework are never matched by the pattern driver.
2024-07-15 16:07:48 +02:00
matchAndRewrite(fir::InsertValueOp insertVal, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
[flang] Make code more homogenous in CodeGen This patch just make the code more similar in each conversion. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D129071
2022-07-04 21:16:13 +02:00
mlir::ValueRange operands = adaptor.getOperands();
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
auto indices = collectIndices(rewriter, insertVal.getCoor());
toRowMajor(indices, operands[0].getType());
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
rewriter.replaceOpWithNewOp<mlir::LLVM::InsertValueOp>(
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
insertVal, operands[0], operands[1], indices);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
};
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// InsertOnRange inserts a value into a sequence over a range of offsets.
struct InsertOnRangeOpConversion
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
: public fir::FIROpAndTypeConversion<fir::InsertOnRangeOp> {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
using FIROpAndTypeConversion::FIROpAndTypeConversion;
// Increments an array of subscripts in a row major fasion.
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
void incrementSubscripts(llvm::ArrayRef<int64_t> dims,
llvm::SmallVectorImpl<int64_t> &subscripts) const {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
for (size_t i = dims.size(); i > 0; --i) {
if (++subscripts[i - 1] < dims[i - 1]) {
return;
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
subscripts[i - 1] = 0;
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
doRewrite(fir::InsertOnRangeOp range, mlir::Type ty, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
llvm::SmallVector<std::int64_t> dims;
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
auto type = adaptor.getOperands()[0].getType();
// Iteratively extract the array dimensions from the type.
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
while (auto t = mlir::dyn_cast<mlir::LLVM::LLVMArrayType>(type)) {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
dims.push_back(t.getNumElements());
type = t.getElementType();
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
}
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
llvm::SmallVector<std::int64_t> lBounds;
llvm::SmallVector<std::int64_t> uBounds;
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// Unzip the upper and lower bound and convert to a row major format.
mlir::DenseIntElementsAttr coor = range.getCoor();
auto reversedCoor = llvm::reverse(coor.getValues<int64_t>());
for (auto i = reversedCoor.begin(), e = reversedCoor.end(); i != e; ++i) {
uBounds.push_back(*i++);
lBounds.push_back(*i);
}
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
auto &subscripts = lBounds;
auto loc = range.getLoc();
mlir::Value lastOp = adaptor.getOperands()[0];
mlir::Value insertVal = adaptor.getOperands()[1];
while (subscripts != uBounds) {
lastOp = rewriter.create<mlir::LLVM::InsertValueOp>(
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
loc, lastOp, insertVal, subscripts);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
incrementSubscripts(dims, subscripts);
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
rewriter.replaceOpWithNewOp<mlir::LLVM::InsertValueOp>(
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
range, lastOp, insertVal, subscripts);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
};
} // namespace
namespace {
/// XArrayCoor is the address arithmetic on a dynamically shaped, sliced,
/// shifted etc. array.
/// (See the static restriction on coordinate_of.) array_coor determines the
/// coordinate (location) of a specific element.
struct XArrayCoorOpConversion
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
: public fir::FIROpAndTypeConversion<fir::cg::XArrayCoorOp> {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
using FIROpAndTypeConversion::FIROpAndTypeConversion;
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
doRewrite(fir::cg::XArrayCoorOp coor, mlir::Type llvmPtrTy, OpAdaptor adaptor,
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::ConversionPatternRewriter &rewriter) const override {
auto loc = coor.getLoc();
mlir::ValueRange operands = adaptor.getOperands();
unsigned rank = coor.getRank();
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
assert(coor.getIndices().size() == rank);
assert(coor.getShape().empty() || coor.getShape().size() == rank);
assert(coor.getShift().empty() || coor.getShift().size() == rank);
assert(coor.getSlice().empty() || coor.getSlice().size() == 3 * rank);
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
mlir::Type idxTy = lowerTy().indexType();
[flang][NFC] rename fircg op operand index accessors (#100584) fircg operations have xxxOffset members to give the operand index of operand xxx. This is a bit weird when looking at usage (e.g. `arrayCoor.shiftOffset` reads like it is shifting some offset). Rename them to getXxxOperandIndex.
2024-07-25 18:02:03 +02:00
unsigned indexOffset = coor.getIndicesOperandIndex();
unsigned shapeOffset = coor.getShapeOperandIndex();
unsigned shiftOffset = coor.getShiftOperandIndex();
unsigned sliceOffset = coor.getSliceOperandIndex();
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
auto sliceOps = coor.getSlice().begin();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::Value one = genConstantIndex(loc, idxTy, rewriter, 1);
mlir::Value prevExt = one;
[mlir][flang] Make use of the new `GEPArg` builder of GEP Op to simplify code This is the follow up on https://reviews.llvm.org/D130730 which goes through upstream code and removes creating constant values in favour of using the constant indices in GEP directly. This leads to less and more readable code and more compact IR as well. Differential Revision: https://reviews.llvm.org/D130731
2022-07-29 01:00:22 +02:00
mlir::Value offset = genConstantIndex(loc, idxTy, rewriter, 0);
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
const bool isShifted = !coor.getShift().empty();
const bool isSliced = !coor.getSlice().empty();
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
const bool baseIsBoxed =
mlir::isa<fir::BaseBoxType>(coor.getMemref().getType());
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
TypePair baseBoxTyPair =
baseIsBoxed ? getBoxTypePair(coor.getMemref().getType()) : TypePair{};
[mlir][llvm] Port `overflowFlags` to a native operation property (RELAND) (#89410) This PR changes the LLVM dialect's IntegerOverflowFlags to be stored on operations as native properties. Reland to fix flang
2024-04-19 09:23:00 -07:00
mlir::LLVM::IntegerOverflowFlags nsw =
mlir::LLVM::IntegerOverflowFlags::nsw;
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// For each dimension of the array, generate the offset calculation.
[Flang] Fixes for XArrayCoorOp The upstreamed code was not incrementing the sliceOffset in multiples of 3. This issue is fixed by using Offsets and incrementing by 3 during every iteration. In the conversion pattern, we were comparing the definingOp of an operand with an FIR::UndefOp. Use LLVM::UndefOp for conversion. Reviewed By: clementval, Leporacanthicus Differential Revision: https://reviews.llvm.org/D128017
2022-06-17 17:07:12 +00:00
for (unsigned i = 0; i < rank; ++i, ++indexOffset, ++shapeOffset,
++shiftOffset, sliceOffset += 3, sliceOps += 3) {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::Value index =
[Flang] Fixes for XArrayCoorOp The upstreamed code was not incrementing the sliceOffset in multiples of 3. This issue is fixed by using Offsets and incrementing by 3 during every iteration. In the conversion pattern, we were comparing the definingOp of an operand with an FIR::UndefOp. Use LLVM::UndefOp for conversion. Reviewed By: clementval, Leporacanthicus Differential Revision: https://reviews.llvm.org/D128017
2022-06-17 17:07:12 +00:00
integerCast(loc, rewriter, idxTy, operands[indexOffset]);
mlir::Value lb =
isShifted ? integerCast(loc, rewriter, idxTy, operands[shiftOffset])
: one;
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::Value step = one;
bool normalSlice = isSliced;
// Compute zero based index in dimension i of the element, applying
// potential triplets and lower bounds.
if (isSliced) {
[Flang] Fixes for XArrayCoorOp The upstreamed code was not incrementing the sliceOffset in multiples of 3. This issue is fixed by using Offsets and incrementing by 3 during every iteration. In the conversion pattern, we were comparing the definingOp of an operand with an FIR::UndefOp. Use LLVM::UndefOp for conversion. Reviewed By: clementval, Leporacanthicus Differential Revision: https://reviews.llvm.org/D128017
2022-06-17 17:07:12 +00:00
mlir::Value originalUb = *(sliceOps + 1);
normalSlice =
!mlir::isa_and_nonnull<fir::UndefOp>(originalUb.getDefiningOp());
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
if (normalSlice)
[Flang] Fixes for XArrayCoorOp The upstreamed code was not incrementing the sliceOffset in multiples of 3. This issue is fixed by using Offsets and incrementing by 3 during every iteration. In the conversion pattern, we were comparing the definingOp of an operand with an FIR::UndefOp. Use LLVM::UndefOp for conversion. Reviewed By: clementval, Leporacanthicus Differential Revision: https://reviews.llvm.org/D128017
2022-06-17 17:07:12 +00:00
step = integerCast(loc, rewriter, idxTy, operands[sliceOffset + 2]);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
[flang][CodeGen] add nsw to address calculations (#74709) `nsw` is a flag for LLVM arithmetic operations meaning "no signed wrap". If this keyword is present, the result of the operation is a poison value if overflow occurs. Adding this keyword permits LLVM to re-order integer arithmetic more aggressively. In https://discourse.llvm.org/t/rfc-changes-to-fircg-xarray-coor-codegen-to-allow-better-hoisting/75257/16 @vzakhari observed that adding nsw is useful to enable hoisting of address calculations after some loops (or is at least a step in that direction). Classic flang also adds nsw to address calculations.
2023-12-08 10:51:20 +00:00
auto idx = rewriter.create<mlir::LLVM::SubOp>(loc, idxTy, index, lb, nsw);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::Value diff =
[flang][CodeGen] add nsw to address calculations (#74709) `nsw` is a flag for LLVM arithmetic operations meaning "no signed wrap". If this keyword is present, the result of the operation is a poison value if overflow occurs. Adding this keyword permits LLVM to re-order integer arithmetic more aggressively. In https://discourse.llvm.org/t/rfc-changes-to-fircg-xarray-coor-codegen-to-allow-better-hoisting/75257/16 @vzakhari observed that adding nsw is useful to enable hoisting of address calculations after some loops (or is at least a step in that direction). Classic flang also adds nsw to address calculations.
2023-12-08 10:51:20 +00:00
rewriter.create<mlir::LLVM::MulOp>(loc, idxTy, idx, step, nsw);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
if (normalSlice) {
mlir::Value sliceLb =
[Flang] Fixes for XArrayCoorOp The upstreamed code was not incrementing the sliceOffset in multiples of 3. This issue is fixed by using Offsets and incrementing by 3 during every iteration. In the conversion pattern, we were comparing the definingOp of an operand with an FIR::UndefOp. Use LLVM::UndefOp for conversion. Reviewed By: clementval, Leporacanthicus Differential Revision: https://reviews.llvm.org/D128017
2022-06-17 17:07:12 +00:00
integerCast(loc, rewriter, idxTy, operands[sliceOffset]);
[flang][CodeGen] add nsw to address calculations (#74709) `nsw` is a flag for LLVM arithmetic operations meaning "no signed wrap". If this keyword is present, the result of the operation is a poison value if overflow occurs. Adding this keyword permits LLVM to re-order integer arithmetic more aggressively. In https://discourse.llvm.org/t/rfc-changes-to-fircg-xarray-coor-codegen-to-allow-better-hoisting/75257/16 @vzakhari observed that adding nsw is useful to enable hoisting of address calculations after some loops (or is at least a step in that direction). Classic flang also adds nsw to address calculations.
2023-12-08 10:51:20 +00:00
auto adj =
rewriter.create<mlir::LLVM::SubOp>(loc, idxTy, sliceLb, lb, nsw);
diff = rewriter.create<mlir::LLVM::AddOp>(loc, idxTy, diff, adj, nsw);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
// Update the offset given the stride and the zero based index `diff`
// that was just computed.
if (baseIsBoxed) {
// Use stride in bytes from the descriptor.
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::Value stride =
getStrideFromBox(loc, baseBoxTyPair, operands[0], i, rewriter);
[flang][CodeGen] add nsw to address calculations (#74709) `nsw` is a flag for LLVM arithmetic operations meaning "no signed wrap". If this keyword is present, the result of the operation is a poison value if overflow occurs. Adding this keyword permits LLVM to re-order integer arithmetic more aggressively. In https://discourse.llvm.org/t/rfc-changes-to-fircg-xarray-coor-codegen-to-allow-better-hoisting/75257/16 @vzakhari observed that adding nsw is useful to enable hoisting of address calculations after some loops (or is at least a step in that direction). Classic flang also adds nsw to address calculations.
2023-12-08 10:51:20 +00:00
auto sc =
rewriter.create<mlir::LLVM::MulOp>(loc, idxTy, diff, stride, nsw);
offset =
rewriter.create<mlir::LLVM::AddOp>(loc, idxTy, sc, offset, nsw);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
} else {
// Use stride computed at last iteration.
[flang][CodeGen] add nsw to address calculations (#74709) `nsw` is a flag for LLVM arithmetic operations meaning "no signed wrap". If this keyword is present, the result of the operation is a poison value if overflow occurs. Adding this keyword permits LLVM to re-order integer arithmetic more aggressively. In https://discourse.llvm.org/t/rfc-changes-to-fircg-xarray-coor-codegen-to-allow-better-hoisting/75257/16 @vzakhari observed that adding nsw is useful to enable hoisting of address calculations after some loops (or is at least a step in that direction). Classic flang also adds nsw to address calculations.
2023-12-08 10:51:20 +00:00
auto sc =
rewriter.create<mlir::LLVM::MulOp>(loc, idxTy, diff, prevExt, nsw);
offset =
rewriter.create<mlir::LLVM::AddOp>(loc, idxTy, sc, offset, nsw);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// Compute next stride assuming contiguity of the base array
// (in element number).
[Flang] Fixes for XArrayCoorOp The upstreamed code was not incrementing the sliceOffset in multiples of 3. This issue is fixed by using Offsets and incrementing by 3 during every iteration. In the conversion pattern, we were comparing the definingOp of an operand with an FIR::UndefOp. Use LLVM::UndefOp for conversion. Reviewed By: clementval, Leporacanthicus Differential Revision: https://reviews.llvm.org/D128017
2022-06-17 17:07:12 +00:00
auto nextExt = integerCast(loc, rewriter, idxTy, operands[shapeOffset]);
[flang][CodeGen] add nsw to address calculations (#74709) `nsw` is a flag for LLVM arithmetic operations meaning "no signed wrap". If this keyword is present, the result of the operation is a poison value if overflow occurs. Adding this keyword permits LLVM to re-order integer arithmetic more aggressively. In https://discourse.llvm.org/t/rfc-changes-to-fircg-xarray-coor-codegen-to-allow-better-hoisting/75257/16 @vzakhari observed that adding nsw is useful to enable hoisting of address calculations after some loops (or is at least a step in that direction). Classic flang also adds nsw to address calculations.
2023-12-08 10:51:20 +00:00
prevExt = rewriter.create<mlir::LLVM::MulOp>(loc, idxTy, prevExt,
nextExt, nsw);
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
}
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// Add computed offset to the base address.
if (baseIsBoxed) {
// Working with byte offsets. The base address is read from the fir.box.
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
// and used in i8* GEP to do the pointer arithmetic.
mlir::Type byteTy = ::getI8Type(coor.getContext());
mlir::Value base =
getBaseAddrFromBox(loc, baseBoxTyPair, operands[0], rewriter);
[mlir][flang] Make use of the new `GEPArg` builder of GEP Op to simplify code This is the follow up on https://reviews.llvm.org/D130730 which goes through upstream code and removes creating constant values in favour of using the constant indices in GEP directly. This leads to less and more readable code and more compact IR as well. Differential Revision: https://reviews.llvm.org/D130731
2022-07-29 01:00:22 +02:00
llvm::SmallVector<mlir::LLVM::GEPArg> args{offset};
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
auto addr = rewriter.create<mlir::LLVM::GEPOp>(loc, llvmPtrTy, byteTy,
base, args);
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
if (coor.getSubcomponent().empty()) {
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
rewriter.replaceOp(coor, addr);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
[flang] fix fir.array_coor of fir.box with component references When dealing with "derived_array(j)%component" where derived_array is not a contiguous array, but for which we know the extent, lowering generates a fir.array_coor op on a !fir.box<!fir.array<cst x T>> with a fir.slice containing "j" in the component path. Codegen first computes "derived_array(j)" address using the byte strides inside the descriptor, and then computes the offset of "j" from that address with a second GEP. The type of the address in that second GEP matters since "j" is passed in the GEP via an index indicating its component position in the type. The code was using the LLVM type of "derived_array" instead of "derived_array(j)". In general, with fir.box, the extent ("cst" above) is unknown and those types match. But if the extent of "derived_array" is a compile time constant, its LLVM type will be [cst x T] instead of T*, and the produced GEP will compute the address of the nth T instead of the nth component inside T leading to undefined behaviors. Fix this by computing the element type for the second GEP. Differential Revision: https://reviews.llvm.org/D148226
2023-04-14 08:47:25 +02:00
// Cast the element address from void* to the derived type so that the
// derived type members can be addresses via a GEP using the index of
// components.
mlir::Type elementType =
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
getLlvmObjectTypeFromBoxType(coor.getMemref().getType());
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
while (auto arrayTy =
mlir::dyn_cast<mlir::LLVM::LLVMArrayType>(elementType))
[flang] fix fir.array_coor of fir.box with component references When dealing with "derived_array(j)%component" where derived_array is not a contiguous array, but for which we know the extent, lowering generates a fir.array_coor op on a !fir.box<!fir.array<cst x T>> with a fir.slice containing "j" in the component path. Codegen first computes "derived_array(j)" address using the byte strides inside the descriptor, and then computes the offset of "j" from that address with a second GEP. The type of the address in that second GEP matters since "j" is passed in the GEP via an index indicating its component position in the type. The code was using the LLVM type of "derived_array" instead of "derived_array(j)". In general, with fir.box, the extent ("cst" above) is unknown and those types match. But if the extent of "derived_array" is a compile time constant, its LLVM type will be [cst x T] instead of T*, and the produced GEP will compute the address of the nth T instead of the nth component inside T leading to undefined behaviors. Fix this by computing the element type for the second GEP. Differential Revision: https://reviews.llvm.org/D148226
2023-04-14 08:47:25 +02:00
elementType = arrayTy.getElementType();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
args.clear();
[mlir][flang] Make use of the new `GEPArg` builder of GEP Op to simplify code This is the follow up on https://reviews.llvm.org/D130730 which goes through upstream code and removes creating constant values in favour of using the constant indices in GEP directly. This leads to less and more readable code and more compact IR as well. Differential Revision: https://reviews.llvm.org/D130731
2022-07-29 01:00:22 +02:00
args.push_back(0);
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
if (!coor.getLenParams().empty()) {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// If type parameters are present, then we don't want to use a GEPOp
// as below, as the LLVM struct type cannot be statically defined.
TODO(loc, "derived type with type parameters");
}
[flang] Fix codegen of subcomponents' indexing Identify multidimensional array indices in subcomponents and convert them from column-major to row-major ordering. This fixes codegen for fircg.ext_array_coor, fircg.ext_embox and, possibly, fircg.ext_rebox. Fixes https://github.com/llvm/llvm-project/issues/62038 Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D154214
2023-06-29 14:46:58 +00:00
llvm::SmallVector<mlir::Value> indices = convertSubcomponentIndices(
loc, elementType,
[flang][NFC] rename fircg op operand index accessors (#100584) fircg operations have xxxOffset members to give the operand index of operand xxx. This is a bit weird when looking at usage (e.g. `arrayCoor.shiftOffset` reads like it is shifting some offset). Rename them to getXxxOperandIndex.
2024-07-25 18:02:03 +02:00
operands.slice(coor.getSubcomponentOperandIndex(),
[flang] Fix codegen of subcomponents' indexing Identify multidimensional array indices in subcomponents and convert them from column-major to row-major ordering. This fixes codegen for fircg.ext_array_coor, fircg.ext_embox and, possibly, fircg.ext_rebox. Fixes https://github.com/llvm/llvm-project/issues/62038 Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D154214
2023-06-29 14:46:58 +00:00
coor.getSubcomponent().size()));
args.append(indices.begin(), indices.end());
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
rewriter.replaceOpWithNewOp<mlir::LLVM::GEPOp>(coor, llvmPtrTy,
elementType, addr, args);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// The array was not boxed, so it must be contiguous. offset is therefore an
// element offset and the base type is kept in the GEP unless the element
// type size is itself dynamic.
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::Type objectTy = fir::unwrapRefType(coor.getMemref().getType());
mlir::Type eleType = fir::unwrapSequenceType(objectTy);
mlir::Type gepObjectType = convertType(eleType);
llvm::SmallVector<mlir::LLVM::GEPArg> args;
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
if (coor.getSubcomponent().empty()) {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// No subcomponent.
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
if (!coor.getLenParams().empty()) {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// Type parameters. Adjust element size explicitly.
auto eleTy = fir::dyn_cast_ptrEleTy(coor.getType());
assert(eleTy && "result must be a reference-like type");
if (fir::characterWithDynamicLen(eleTy)) {
[flang][NFC] Use prefixed accessors for fircg dialect The raw accessor is going away soon so switch to prefixed accessors in the fircg dialect. The main dialect was switched some months ago. https://github.com/llvm/llvm-project/issues/58090 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D135061
2022-10-03 11:02:23 +02:00
assert(coor.getLenParams().size() == 1);
[flang] Fix lowering issue with character temp - Add verifiers that determine if an Op requires type parameters or not and checks that the correct number of parameters is specified. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D128828 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2022-06-29 20:06:11 +02:00
auto length = integerCast(loc, rewriter, idxTy,
[flang][NFC] rename fircg op operand index accessors (#100584) fircg operations have xxxOffset members to give the operand index of operand xxx. This is a bit weird when looking at usage (e.g. `arrayCoor.shiftOffset` reads like it is shifting some offset). Rename them to getXxxOperandIndex.
2024-07-25 18:02:03 +02:00
operands[coor.getLenParamsOperandIndex()]);
[flang][CodeGen] add nsw to address calculations (#74709) `nsw` is a flag for LLVM arithmetic operations meaning "no signed wrap". If this keyword is present, the result of the operation is a poison value if overflow occurs. Adding this keyword permits LLVM to re-order integer arithmetic more aggressively. In https://discourse.llvm.org/t/rfc-changes-to-fircg-xarray-coor-codegen-to-allow-better-hoisting/75257/16 @vzakhari observed that adding nsw is useful to enable hoisting of address calculations after some loops (or is at least a step in that direction). Classic flang also adds nsw to address calculations.
2023-12-08 10:51:20 +00:00
offset = rewriter.create<mlir::LLVM::MulOp>(loc, idxTy, offset,
length, nsw);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
} else {
TODO(loc, "compute size of derived type with type parameters");
}
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
}
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
args.push_back(offset);
} else {
// There are subcomponents.
args.push_back(offset);
[flang] Fix codegen of subcomponents' indexing Identify multidimensional array indices in subcomponents and convert them from column-major to row-major ordering. This fixes codegen for fircg.ext_array_coor, fircg.ext_embox and, possibly, fircg.ext_rebox. Fixes https://github.com/llvm/llvm-project/issues/62038 Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D154214
2023-06-29 14:46:58 +00:00
llvm::SmallVector<mlir::Value> indices = convertSubcomponentIndices(
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
loc, gepObjectType,
[flang][NFC] rename fircg op operand index accessors (#100584) fircg operations have xxxOffset members to give the operand index of operand xxx. This is a bit weird when looking at usage (e.g. `arrayCoor.shiftOffset` reads like it is shifting some offset). Rename them to getXxxOperandIndex.
2024-07-25 18:02:03 +02:00
operands.slice(coor.getSubcomponentOperandIndex(),
[flang] Fix codegen of subcomponents' indexing Identify multidimensional array indices in subcomponents and convert them from column-major to row-major ordering. This fixes codegen for fircg.ext_array_coor, fircg.ext_embox and, possibly, fircg.ext_rebox. Fixes https://github.com/llvm/llvm-project/issues/62038 Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D154214
2023-06-29 14:46:58 +00:00
coor.getSubcomponent().size()));
args.append(indices.begin(), indices.end());
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
}
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
rewriter.replaceOpWithNewOp<mlir::LLVM::GEPOp>(
coor, llvmPtrTy, gepObjectType, adaptor.getMemref(), args);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
};
} // namespace
/// Convert to (memory) reference to a reference to a subobject.
/// The coordinate_of op is a Swiss army knife operation that can be used on
/// (memory) references to records, arrays, complex, etc. as well as boxes.
/// With unboxed arrays, there is the restriction that the array have a static
/// shape in all but the last column.
struct CoordinateOpConversion
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
: public fir::FIROpAndTypeConversion<fir::CoordinateOp> {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
using FIROpAndTypeConversion::FIROpAndTypeConversion;
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
doRewrite(fir::CoordinateOp coor, mlir::Type ty, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
mlir::ValueRange operands = adaptor.getOperands();
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::Location loc = coor.getLoc();
mlir::Value base = operands[0];
mlir::Type baseObjectTy = coor.getBaseType();
mlir::Type objectTy = fir::dyn_cast_ptrOrBoxEleTy(baseObjectTy);
assert(objectTy && "fir.coordinate_of expects a reference type");
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::Type llvmObjectTy = convertType(objectTy);
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// Complex type - basically, extract the real or imaginary part
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
// FIXME: double check why this is done before the fir.box case below.
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
if (fir::isa_complex(objectTy)) {
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::Value gep =
genGEP(loc, llvmObjectTy, rewriter, base, 0, operands[1]);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
rewriter.replaceOp(coor, gep);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// Boxed type - get the base pointer from the box
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (mlir::dyn_cast<fir::BaseBoxType>(baseObjectTy))
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
return doRewriteBox(coor, operands, loc, rewriter);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
[flang] Update the conversion code for fir.coordinate_of These are mostly small changes to make the code a bit clearer and more consistent. Summary of changes: * add missing namespace qualifiers (that's the preference in Flang) * replace const member methods with static methods (to avoid passing the *this pointer unnecessarily) * rename `currentObjTy` (current object type) as `cpnTy` (component type) - the latter feels more fitting * remove redundant `return failure();` calls (` return mlir::emitError` gives the same result) * updated a few comments Differential Revision: https://reviews.llvm.org/D122799
2022-03-28 16:13:59 +00:00
// Reference, pointer or a heap type
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (mlir::isa<fir::ReferenceType, fir::PointerType, fir::HeapType>(
baseObjectTy))
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
return doRewriteRefOrPtr(coor, llvmObjectTy, operands, loc, rewriter);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
return rewriter.notifyMatchFailure(
coor, "fir.coordinate_of base operand has unsupported type");
[Flang] Upstream conversion of the XRebox Op The XRebox Op is formed by the codegen rewrite which makes it easier to convert the operation to LLVM. The XRebox op includes the information from the rebox op and the associated slice, shift, and shape ops. During the conversion process a new descriptor is created for reboxing. Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D114709
2021-12-07 13:01:28 +00:00
}
[flang] Update the conversion code for fir.coordinate_of These are mostly small changes to make the code a bit clearer and more consistent. Summary of changes: * add missing namespace qualifiers (that's the preference in Flang) * replace const member methods with static methods (to avoid passing the *this pointer unnecessarily) * rename `currentObjTy` (current object type) as `cpnTy` (component type) - the latter feels more fitting * remove redundant `return failure();` calls (` return mlir::emitError` gives the same result) * updated a few comments Differential Revision: https://reviews.llvm.org/D122799
2022-03-28 16:13:59 +00:00
static unsigned getFieldNumber(fir::RecordType ty, mlir::Value op) {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
return fir::hasDynamicSize(ty)
? op.getDefiningOp()
->getAttrOfType<mlir::IntegerAttr>("field")
.getInt()
[flang] Merge GEPs in substring fir.embox codegen When computing the base addresses of an array slice to make a descriptor, codegen generated two LLVM GEPs. The first to compute the address of the base character element, and a second one to compute the substring base inside that element. The previous code did not care about getting the result of the first GEP right: it used the base array LLVM type as the result type. This used to work when opaque pointer were not enabled (the actual GEP result type was probably applied in some later pass). But with opaque pointers, the second GEP ends-up computing an offset of len*<LLVM array type> instead of len*<character width>. A previous attempt to fix the issue was done in D129079, but it does not cover the cases where the array slice contains subcomponents before the substring (e.g: array(:)%char_field(5:10)). This patch fix the issue by computing the actual GEP result type in codegen. There is also enough knowledge now so that a single GEP can be generated instead of two. Differential Revision: https://reviews.llvm.org/D129481
2022-07-12 09:26:16 +02:00
: getConstantIntValue(op);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
[flang] Update the conversion code for fir.coordinate_of These are mostly small changes to make the code a bit clearer and more consistent. Summary of changes: * add missing namespace qualifiers (that's the preference in Flang) * replace const member methods with static methods (to avoid passing the *this pointer unnecessarily) * rename `currentObjTy` (current object type) as `cpnTy` (component type) - the latter feels more fitting * remove redundant `return failure();` calls (` return mlir::emitError` gives the same result) * updated a few comments Differential Revision: https://reviews.llvm.org/D122799
2022-03-28 16:13:59 +00:00
static bool hasSubDimensions(mlir::Type type) {
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
return mlir::isa<fir::SequenceType, fir::RecordType, mlir::TupleType>(type);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
[flang] update fir.coordinate_of to carry the fields (#127231) This patch updates fir.coordinate_op to carry the field index as attributes instead of relying on getting it from the fir.field_index operations defining its operands. The rational is that FIR currently has a few operations that require DAGs to be preserved in order to be able to do code generation. This is the case of fir.coordinate_op, which requires its fir.field operand producer to be visible. This makes IR transformation harder/brittle, so I want to update FIR to get rid if this. Codegen/printer/parser of fir.coordinate_of and many tests need to be updated after this change.
2025-02-28 09:50:05 +01:00
// Helper structure to analyze the CoordinateOp path and decide if and how
// the GEP should be generated for it.
struct ShapeAnalysis {
bool hasKnownShape;
bool columnIsDeferred;
};
[fir] Add fir.extract_value and fir.insert_value conversion This patch add the conversion pattern for fir.extract_value and fir.insert_value. fir.extract_value is lowered to llvm.extractvalue anf fir.insert_value is lowered to llvm.insertvalue. This patch also adds the type conversion for the BoxType and RecordType needed to have some comprehensive tests. This patch is part of the upstreaming effort from fir-dev branch. This patch was landed and reverted once. TypeBuilderFunc getModel<Fortran::ISO::CFI_index_t>() was clashing with getModel<long long> on windows since they both are 64 bits signed interger. On linux CFI_index_t is long. Change CFI_index_t to getModel<long>. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D112961 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-07 14:43:00 +01:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// Walk the abstract memory layout and determine if the path traverses any
/// array types with unknown shape. Return true iff all the array types have a
/// constant shape along the path.
[flang] update fir.coordinate_of to carry the fields (#127231) This patch updates fir.coordinate_op to carry the field index as attributes instead of relying on getting it from the fir.field_index operations defining its operands. The rational is that FIR currently has a few operations that require DAGs to be preserved in order to be able to do code generation. This is the case of fir.coordinate_op, which requires its fir.field operand producer to be visible. This makes IR transformation harder/brittle, so I want to update FIR to get rid if this. Codegen/printer/parser of fir.coordinate_of and many tests need to be updated after this change.
2025-02-28 09:50:05 +01:00
/// TODO: move the verification logic into the verifier.
static std::optional<ShapeAnalysis>
arraysHaveKnownShape(mlir::Type type, fir::CoordinateOp coor) {
fir::CoordinateIndicesAdaptor indices = coor.getIndices();
auto begin = indices.begin();
bool hasKnownShape = true;
bool columnIsDeferred = false;
for (auto it = begin, end = indices.end(); it != end;) {
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (auto arrTy = mlir::dyn_cast<fir::SequenceType>(type)) {
[flang] update fir.coordinate_of to carry the fields (#127231) This patch updates fir.coordinate_op to carry the field index as attributes instead of relying on getting it from the fir.field_index operations defining its operands. The rational is that FIR currently has a few operations that require DAGs to be preserved in order to be able to do code generation. This is the case of fir.coordinate_op, which requires its fir.field operand producer to be visible. This makes IR transformation harder/brittle, so I want to update FIR to get rid if this. Codegen/printer/parser of fir.coordinate_of and many tests need to be updated after this change.
2025-02-28 09:50:05 +01:00
bool addressingStart = (it == begin);
unsigned arrayDim = arrTy.getDimension();
for (auto dimExtent : llvm::enumerate(arrTy.getShape())) {
if (dimExtent.value() == fir::SequenceType::getUnknownExtent()) {
hasKnownShape = false;
if (addressingStart && dimExtent.index() + 1 == arrayDim) {
// If this point was reached, the raws of the first array have
// constant extents.
columnIsDeferred = true;
} else {
// One of the array dimension that is not the column of the first
// array has dynamic extent. It will not possible to do
// code generation for the CoordinateOp if the base is not a
// fir.box containing the value of that extent.
return ShapeAnalysis{false, false};
}
}
// There may be less operands than the array size if the
// fir.coordinate_of result is not an element but a sub-array.
if (it != end)
++it;
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
type = arrTy.getEleTy();
[flang] update fir.coordinate_of to carry the fields (#127231) This patch updates fir.coordinate_op to carry the field index as attributes instead of relying on getting it from the fir.field_index operations defining its operands. The rational is that FIR currently has a few operations that require DAGs to be preserved in order to be able to do code generation. This is the case of fir.coordinate_op, which requires its fir.field operand producer to be visible. This makes IR transformation harder/brittle, so I want to update FIR to get rid if this. Codegen/printer/parser of fir.coordinate_of and many tests need to be updated after this change.
2025-02-28 09:50:05 +01:00
continue;
}
if (auto strTy = mlir::dyn_cast<fir::RecordType>(type)) {
auto intAttr = llvm::dyn_cast<mlir::IntegerAttr>(*it);
if (!intAttr) {
mlir::emitError(coor.getLoc(),
"expected field name in fir.coordinate_of");
return std::nullopt;
}
type = strTy.getType(intAttr.getInt());
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
} else if (auto strTy = mlir::dyn_cast<mlir::TupleType>(type)) {
[flang] update fir.coordinate_of to carry the fields (#127231) This patch updates fir.coordinate_op to carry the field index as attributes instead of relying on getting it from the fir.field_index operations defining its operands. The rational is that FIR currently has a few operations that require DAGs to be preserved in order to be able to do code generation. This is the case of fir.coordinate_op, which requires its fir.field operand producer to be visible. This makes IR transformation harder/brittle, so I want to update FIR to get rid if this. Codegen/printer/parser of fir.coordinate_of and many tests need to be updated after this change.
2025-02-28 09:50:05 +01:00
auto value = llvm::dyn_cast<mlir::Value>(*it);
if (!value) {
mlir::emitError(
coor.getLoc(),
"expected constant value to address tuple in fir.coordinate_of");
return std::nullopt;
}
type = strTy.getType(getConstantIntValue(value));
} else if (auto charType = mlir::dyn_cast<fir::CharacterType>(type)) {
// Addressing character in string. Fortran strings degenerate to arrays
// in LLVM, so they are handled like arrays of characters here.
if (charType.getLen() == fir::CharacterType::unknownLen())
return ShapeAnalysis{false, true};
type = fir::CharacterType::getSingleton(charType.getContext(),
charType.getFKind());
[fir] Add fir.extract_value and fir.insert_value conversion This patch add the conversion pattern for fir.extract_value and fir.insert_value. fir.extract_value is lowered to llvm.extractvalue anf fir.insert_value is lowered to llvm.insertvalue. This patch also adds the type conversion for the BoxType and RecordType needed to have some comprehensive tests. This patch is part of the upstreaming effort from fir-dev branch. This patch was landed and reverted once. TypeBuilderFunc getModel<Fortran::ISO::CFI_index_t>() was clashing with getModel<long long> on windows since they both are 64 bits signed interger. On linux CFI_index_t is long. Change CFI_index_t to getModel<long>. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D112961 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-07 14:43:00 +01:00
}
[flang] update fir.coordinate_of to carry the fields (#127231) This patch updates fir.coordinate_op to carry the field index as attributes instead of relying on getting it from the fir.field_index operations defining its operands. The rational is that FIR currently has a few operations that require DAGs to be preserved in order to be able to do code generation. This is the case of fir.coordinate_op, which requires its fir.field operand producer to be visible. This makes IR transformation harder/brittle, so I want to update FIR to get rid if this. Codegen/printer/parser of fir.coordinate_of and many tests need to be updated after this change.
2025-02-28 09:50:05 +01:00
++it;
[fir] Add fir.extract_value and fir.insert_value conversion This patch add the conversion pattern for fir.extract_value and fir.insert_value. fir.extract_value is lowered to llvm.extractvalue anf fir.insert_value is lowered to llvm.insertvalue. This patch also adds the type conversion for the BoxType and RecordType needed to have some comprehensive tests. This patch is part of the upstreaming effort from fir-dev branch. This patch was landed and reverted once. TypeBuilderFunc getModel<Fortran::ISO::CFI_index_t>() was clashing with getModel<long long> on windows since they both are 64 bits signed interger. On linux CFI_index_t is long. Change CFI_index_t to getModel<long>. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D112961 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-07 14:43:00 +01:00
}
[flang] update fir.coordinate_of to carry the fields (#127231) This patch updates fir.coordinate_op to carry the field index as attributes instead of relying on getting it from the fir.field_index operations defining its operands. The rational is that FIR currently has a few operations that require DAGs to be preserved in order to be able to do code generation. This is the case of fir.coordinate_op, which requires its fir.field operand producer to be visible. This makes IR transformation harder/brittle, so I want to update FIR to get rid if this. Codegen/printer/parser of fir.coordinate_of and many tests need to be updated after this change.
2025-02-28 09:50:05 +01:00
return ShapeAnalysis{hasKnownShape, columnIsDeferred};
[fir] Add fir.extract_value and fir.insert_value conversion This patch add the conversion pattern for fir.extract_value and fir.insert_value. fir.extract_value is lowered to llvm.extractvalue anf fir.insert_value is lowered to llvm.insertvalue. This patch also adds the type conversion for the BoxType and RecordType needed to have some comprehensive tests. This patch is part of the upstreaming effort from fir-dev branch. This patch was landed and reverted once. TypeBuilderFunc getModel<Fortran::ISO::CFI_index_t>() was clashing with getModel<long long> on windows since they both are 64 bits signed interger. On linux CFI_index_t is long. Change CFI_index_t to getModel<long>. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D112961 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-07 14:43:00 +01:00
}
private:
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
doRewriteBox(fir::CoordinateOp coor, mlir::ValueRange operands,
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::Location loc,
mlir::ConversionPatternRewriter &rewriter) const {
mlir::Type boxObjTy = coor.getBaseType();
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
assert(mlir::dyn_cast<fir::BaseBoxType>(boxObjTy) &&
"This is not a `fir.box`");
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
TypePair boxTyPair = getBoxTypePair(boxObjTy);
[fir] Add fir.extract_value and fir.insert_value conversion This patch add the conversion pattern for fir.extract_value and fir.insert_value. fir.extract_value is lowered to llvm.extractvalue anf fir.insert_value is lowered to llvm.insertvalue. This patch also adds the type conversion for the BoxType and RecordType needed to have some comprehensive tests. This patch is part of the upstreaming effort from fir-dev branch. This patch was landed and reverted once. TypeBuilderFunc getModel<Fortran::ISO::CFI_index_t>() was clashing with getModel<long long> on windows since they both are 64 bits signed interger. On linux CFI_index_t is long. Change CFI_index_t to getModel<long>. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D112961 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-07 14:43:00 +01:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::Value boxBaseAddr = operands[0];
[fir] Add fir.extract_value and fir.insert_value conversion This patch add the conversion pattern for fir.extract_value and fir.insert_value. fir.extract_value is lowered to llvm.extractvalue anf fir.insert_value is lowered to llvm.insertvalue. This patch also adds the type conversion for the BoxType and RecordType needed to have some comprehensive tests. This patch is part of the upstreaming effort from fir-dev branch. This patch was landed and reverted once. TypeBuilderFunc getModel<Fortran::ISO::CFI_index_t>() was clashing with getModel<long long> on windows since they both are 64 bits signed interger. On linux CFI_index_t is long. Change CFI_index_t to getModel<long>. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D112961 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-07 14:43:00 +01:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// 1. SPECIAL CASE (uses `fir.len_param_index`):
// %box = ... : !fir.box<!fir.type<derived{len1:i32}>>
// %lenp = fir.len_param_index len1, !fir.type<derived{len1:i32}>
// %addr = coordinate_of %box, %lenp
if (coor.getNumOperands() == 2) {
mlir::Operation *coordinateDef =
(*coor.getCoor().begin()).getDefiningOp();
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
if (mlir::isa_and_nonnull<fir::LenParamIndexOp>(coordinateDef))
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
TODO(loc,
"fir.coordinate_of - fir.len_param_index is not supported yet");
}
[fir] Add fir.extract_value and fir.insert_value conversion This patch add the conversion pattern for fir.extract_value and fir.insert_value. fir.extract_value is lowered to llvm.extractvalue anf fir.insert_value is lowered to llvm.insertvalue. This patch also adds the type conversion for the BoxType and RecordType needed to have some comprehensive tests. This patch is part of the upstreaming effort from fir-dev branch. This patch was landed and reverted once. TypeBuilderFunc getModel<Fortran::ISO::CFI_index_t>() was clashing with getModel<long long> on windows since they both are 64 bits signed interger. On linux CFI_index_t is long. Change CFI_index_t to getModel<long>. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D112961 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-07 14:43:00 +01:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// 2. GENERAL CASE:
// 2.1. (`fir.array`)
// %box = ... : !fix.box<!fir.array<?xU>>
// %idx = ... : index
// %resultAddr = coordinate_of %box, %idx : !fir.ref<U>
// 2.2 (`fir.derived`)
// %box = ... : !fix.box<!fir.type<derived_type{field_1:i32}>>
// %idx = ... : i32
// %resultAddr = coordinate_of %box, %idx : !fir.ref<i32>
// 2.3 (`fir.derived` inside `fir.array`)
// %box = ... : !fir.box<!fir.array<10 x !fir.type<derived_1{field_1:f32,
// field_2:f32}>>> %idx1 = ... : index %idx2 = ... : i32 %resultAddr =
// coordinate_of %box, %idx1, %idx2 : !fir.ref<f32>
// 2.4. TODO: Either document or disable any other case that the following
// implementation might convert.
mlir::Value resultAddr =
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
getBaseAddrFromBox(loc, boxTyPair, boxBaseAddr, rewriter);
[flang] Update the conversion code for fir.coordinate_of These are mostly small changes to make the code a bit clearer and more consistent. Summary of changes: * add missing namespace qualifiers (that's the preference in Flang) * replace const member methods with static methods (to avoid passing the *this pointer unnecessarily) * rename `currentObjTy` (current object type) as `cpnTy` (component type) - the latter feels more fitting * remove redundant `return failure();` calls (` return mlir::emitError` gives the same result) * updated a few comments Differential Revision: https://reviews.llvm.org/D122799
2022-03-28 16:13:59 +00:00
// Component Type
auto cpnTy = fir::dyn_cast_ptrOrBoxEleTy(boxObjTy);
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::Type llvmPtrTy = ::getLlvmPtrType(coor.getContext());
mlir::Type byteTy = ::getI8Type(coor.getContext());
[mlir][llvm] Port `overflowFlags` to a native operation property (RELAND) (#89410) This PR changes the LLVM dialect's IntegerOverflowFlags to be stored on operations as native properties. Reland to fix flang
2024-04-19 09:23:00 -07:00
mlir::LLVM::IntegerOverflowFlags nsw =
mlir::LLVM::IntegerOverflowFlags::nsw;
[fir] Add fir.insert_on_range conversion Convert fir.insert_on_range operation to corresponding llvm.insertvalue operations. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D112896
2021-11-04 10:36:00 +01:00
[flang] update fir.coordinate_of to carry the fields (#127231) This patch updates fir.coordinate_op to carry the field index as attributes instead of relying on getting it from the fir.field_index operations defining its operands. The rational is that FIR currently has a few operations that require DAGs to be preserved in order to be able to do code generation. This is the case of fir.coordinate_op, which requires its fir.field operand producer to be visible. This makes IR transformation harder/brittle, so I want to update FIR to get rid if this. Codegen/printer/parser of fir.coordinate_of and many tests need to be updated after this change.
2025-02-28 09:50:05 +01:00
int nextIndexValue = 1;
fir::CoordinateIndicesAdaptor indices = coor.getIndices();
for (auto it = indices.begin(), end = indices.end(); it != end;) {
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (auto arrTy = mlir::dyn_cast<fir::SequenceType>(cpnTy)) {
[flang] update fir.coordinate_of to carry the fields (#127231) This patch updates fir.coordinate_op to carry the field index as attributes instead of relying on getting it from the fir.field_index operations defining its operands. The rational is that FIR currently has a few operations that require DAGs to be preserved in order to be able to do code generation. This is the case of fir.coordinate_op, which requires its fir.field operand producer to be visible. This makes IR transformation harder/brittle, so I want to update FIR to get rid if this. Codegen/printer/parser of fir.coordinate_of and many tests need to be updated after this change.
2025-02-28 09:50:05 +01:00
if (it != indices.begin())
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
TODO(loc, "fir.array nested inside other array and/or derived type");
// Applies byte strides from the box. Ignore lower bound from box
// since fir.coordinate_of indexes are zero based. Lowering takes care
// of lower bound aspects. This both accounts for dynamically sized
// types and non contiguous arrays.
auto idxTy = lowerTy().indexType();
mlir::Value off = genConstantIndex(loc, idxTy, rewriter, 0);
[flang] update fir.coordinate_of to carry the fields (#127231) This patch updates fir.coordinate_op to carry the field index as attributes instead of relying on getting it from the fir.field_index operations defining its operands. The rational is that FIR currently has a few operations that require DAGs to be preserved in order to be able to do code generation. This is the case of fir.coordinate_op, which requires its fir.field operand producer to be visible. This makes IR transformation harder/brittle, so I want to update FIR to get rid if this. Codegen/printer/parser of fir.coordinate_of and many tests need to be updated after this change.
2025-02-28 09:50:05 +01:00
unsigned arrayDim = arrTy.getDimension();
for (unsigned dim = 0; dim < arrayDim && it != end; ++dim, ++it) {
mlir::Value stride =
getStrideFromBox(loc, boxTyPair, operands[0], dim, rewriter);
[flang][CodeGen] add nsw to address calculations (#74709) `nsw` is a flag for LLVM arithmetic operations meaning "no signed wrap". If this keyword is present, the result of the operation is a poison value if overflow occurs. Adding this keyword permits LLVM to re-order integer arithmetic more aggressively. In https://discourse.llvm.org/t/rfc-changes-to-fircg-xarray-coor-codegen-to-allow-better-hoisting/75257/16 @vzakhari observed that adding nsw is useful to enable hoisting of address calculations after some loops (or is at least a step in that direction). Classic flang also adds nsw to address calculations.
2023-12-08 10:51:20 +00:00
auto sc = rewriter.create<mlir::LLVM::MulOp>(
[flang] update fir.coordinate_of to carry the fields (#127231) This patch updates fir.coordinate_op to carry the field index as attributes instead of relying on getting it from the fir.field_index operations defining its operands. The rational is that FIR currently has a few operations that require DAGs to be preserved in order to be able to do code generation. This is the case of fir.coordinate_op, which requires its fir.field operand producer to be visible. This makes IR transformation harder/brittle, so I want to update FIR to get rid if this. Codegen/printer/parser of fir.coordinate_of and many tests need to be updated after this change.
2025-02-28 09:50:05 +01:00
loc, idxTy, operands[nextIndexValue + dim], stride, nsw);
[flang][CodeGen] add nsw to address calculations (#74709) `nsw` is a flag for LLVM arithmetic operations meaning "no signed wrap". If this keyword is present, the result of the operation is a poison value if overflow occurs. Adding this keyword permits LLVM to re-order integer arithmetic more aggressively. In https://discourse.llvm.org/t/rfc-changes-to-fircg-xarray-coor-codegen-to-allow-better-hoisting/75257/16 @vzakhari observed that adding nsw is useful to enable hoisting of address calculations after some loops (or is at least a step in that direction). Classic flang also adds nsw to address calculations.
2023-12-08 10:51:20 +00:00
off = rewriter.create<mlir::LLVM::AddOp>(loc, idxTy, sc, off, nsw);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
[flang] update fir.coordinate_of to carry the fields (#127231) This patch updates fir.coordinate_op to carry the field index as attributes instead of relying on getting it from the fir.field_index operations defining its operands. The rational is that FIR currently has a few operations that require DAGs to be preserved in order to be able to do code generation. This is the case of fir.coordinate_op, which requires its fir.field operand producer to be visible. This makes IR transformation harder/brittle, so I want to update FIR to get rid if this. Codegen/printer/parser of fir.coordinate_of and many tests need to be updated after this change.
2025-02-28 09:50:05 +01:00
nextIndexValue += arrayDim;
[mlir][flang] Make use of the new `GEPArg` builder of GEP Op to simplify code This is the follow up on https://reviews.llvm.org/D130730 which goes through upstream code and removes creating constant values in favour of using the constant indices in GEP directly. This leads to less and more readable code and more compact IR as well. Differential Revision: https://reviews.llvm.org/D130731
2022-07-29 01:00:22 +02:00
resultAddr = rewriter.create<mlir::LLVM::GEPOp>(
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
loc, llvmPtrTy, byteTy, resultAddr,
[mlir][flang] Make use of the new `GEPArg` builder of GEP Op to simplify code This is the follow up on https://reviews.llvm.org/D130730 which goes through upstream code and removes creating constant values in favour of using the constant indices in GEP directly. This leads to less and more readable code and more compact IR as well. Differential Revision: https://reviews.llvm.org/D130731
2022-07-29 01:00:22 +02:00
llvm::ArrayRef<mlir::LLVM::GEPArg>{off});
[flang] Update the conversion code for fir.coordinate_of These are mostly small changes to make the code a bit clearer and more consistent. Summary of changes: * add missing namespace qualifiers (that's the preference in Flang) * replace const member methods with static methods (to avoid passing the *this pointer unnecessarily) * rename `currentObjTy` (current object type) as `cpnTy` (component type) - the latter feels more fitting * remove redundant `return failure();` calls (` return mlir::emitError` gives the same result) * updated a few comments Differential Revision: https://reviews.llvm.org/D122799
2022-03-28 16:13:59 +00:00
cpnTy = arrTy.getEleTy();
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
} else if (auto recTy = mlir::dyn_cast<fir::RecordType>(cpnTy)) {
[flang] update fir.coordinate_of to carry the fields (#127231) This patch updates fir.coordinate_op to carry the field index as attributes instead of relying on getting it from the fir.field_index operations defining its operands. The rational is that FIR currently has a few operations that require DAGs to be preserved in order to be able to do code generation. This is the case of fir.coordinate_op, which requires its fir.field operand producer to be visible. This makes IR transformation harder/brittle, so I want to update FIR to get rid if this. Codegen/printer/parser of fir.coordinate_of and many tests need to be updated after this change.
2025-02-28 09:50:05 +01:00
auto intAttr = llvm::dyn_cast<mlir::IntegerAttr>(*it);
if (!intAttr)
return mlir::emitError(loc,
"expected field name in fir.coordinate_of");
int fieldIndex = intAttr.getInt();
++it;
cpnTy = recTy.getType(fieldIndex);
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
auto llvmRecTy = lowerTy().convertType(recTy);
resultAddr = rewriter.create<mlir::LLVM::GEPOp>(
loc, llvmPtrTy, llvmRecTy, resultAddr,
[flang] update fir.coordinate_of to carry the fields (#127231) This patch updates fir.coordinate_op to carry the field index as attributes instead of relying on getting it from the fir.field_index operations defining its operands. The rational is that FIR currently has a few operations that require DAGs to be preserved in order to be able to do code generation. This is the case of fir.coordinate_op, which requires its fir.field operand producer to be visible. This makes IR transformation harder/brittle, so I want to update FIR to get rid if this. Codegen/printer/parser of fir.coordinate_of and many tests need to be updated after this change.
2025-02-28 09:50:05 +01:00
llvm::ArrayRef<mlir::LLVM::GEPArg>{0, fieldIndex});
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
} else {
fir::emitFatalError(loc, "unexpected type in coordinate_of");
[fir] Add fir.insert_on_range conversion Convert fir.insert_on_range operation to corresponding llvm.insertvalue operations. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D112896
2021-11-04 10:36:00 +01:00
}
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
rewriter.replaceOp(coor, resultAddr);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[fir] Add fir.insert_on_range conversion Convert fir.insert_on_range operation to corresponding llvm.insertvalue operations. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D112896
2021-11-04 10:36:00 +01:00
}
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
doRewriteRefOrPtr(fir::CoordinateOp coor, mlir::Type llvmObjectTy,
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::ValueRange operands, mlir::Location loc,
mlir::ConversionPatternRewriter &rewriter) const {
mlir::Type baseObjectTy = coor.getBaseType();
[fir] Add fir.insert_on_range conversion Convert fir.insert_on_range operation to corresponding llvm.insertvalue operations. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D112896
2021-11-04 10:36:00 +01:00
[flang] Update the conversion code for fir.coordinate_of These are mostly small changes to make the code a bit clearer and more consistent. Summary of changes: * add missing namespace qualifiers (that's the preference in Flang) * replace const member methods with static methods (to avoid passing the *this pointer unnecessarily) * rename `currentObjTy` (current object type) as `cpnTy` (component type) - the latter feels more fitting * remove redundant `return failure();` calls (` return mlir::emitError` gives the same result) * updated a few comments Differential Revision: https://reviews.llvm.org/D122799
2022-03-28 16:13:59 +00:00
// Component Type
mlir::Type cpnTy = fir::dyn_cast_ptrOrBoxEleTy(baseObjectTy);
[flang] update fir.coordinate_of to carry the fields (#127231) This patch updates fir.coordinate_op to carry the field index as attributes instead of relying on getting it from the fir.field_index operations defining its operands. The rational is that FIR currently has a few operations that require DAGs to be preserved in order to be able to do code generation. This is the case of fir.coordinate_op, which requires its fir.field operand producer to be visible. This makes IR transformation harder/brittle, so I want to update FIR to get rid if this. Codegen/printer/parser of fir.coordinate_of and many tests need to be updated after this change.
2025-02-28 09:50:05 +01:00
const std::optional<ShapeAnalysis> shapeAnalysis =
arraysHaveKnownShape(cpnTy, coor);
if (!shapeAnalysis)
return mlir::failure();
[fir] Add fir.insert_on_range conversion Convert fir.insert_on_range operation to corresponding llvm.insertvalue operations. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D112896
2021-11-04 10:36:00 +01:00
[flang] Update the conversion code for fir.coordinate_of These are mostly small changes to make the code a bit clearer and more consistent. Summary of changes: * add missing namespace qualifiers (that's the preference in Flang) * replace const member methods with static methods (to avoid passing the *this pointer unnecessarily) * rename `currentObjTy` (current object type) as `cpnTy` (component type) - the latter feels more fitting * remove redundant `return failure();` calls (` return mlir::emitError` gives the same result) * updated a few comments Differential Revision: https://reviews.llvm.org/D122799
2022-03-28 16:13:59 +00:00
if (fir::hasDynamicSize(fir::unwrapSequenceType(cpnTy)))
return mlir::emitError(
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
loc, "fir.coordinate_of with a dynamic element size is unsupported");
[fir] Add fir.insert_on_range conversion Convert fir.insert_on_range operation to corresponding llvm.insertvalue operations. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D112896
2021-11-04 10:36:00 +01:00
[flang] update fir.coordinate_of to carry the fields (#127231) This patch updates fir.coordinate_op to carry the field index as attributes instead of relying on getting it from the fir.field_index operations defining its operands. The rational is that FIR currently has a few operations that require DAGs to be preserved in order to be able to do code generation. This is the case of fir.coordinate_op, which requires its fir.field operand producer to be visible. This makes IR transformation harder/brittle, so I want to update FIR to get rid if this. Codegen/printer/parser of fir.coordinate_of and many tests need to be updated after this change.
2025-02-28 09:50:05 +01:00
if (shapeAnalysis->hasKnownShape || shapeAnalysis->columnIsDeferred) {
[mlir][flang] Make use of the new `GEPArg` builder of GEP Op to simplify code This is the follow up on https://reviews.llvm.org/D130730 which goes through upstream code and removes creating constant values in favour of using the constant indices in GEP directly. This leads to less and more readable code and more compact IR as well. Differential Revision: https://reviews.llvm.org/D130731
2022-07-29 01:00:22 +02:00
llvm::SmallVector<mlir::LLVM::GEPArg> offs;
[flang] update fir.coordinate_of to carry the fields (#127231) This patch updates fir.coordinate_op to carry the field index as attributes instead of relying on getting it from the fir.field_index operations defining its operands. The rational is that FIR currently has a few operations that require DAGs to be preserved in order to be able to do code generation. This is the case of fir.coordinate_op, which requires its fir.field operand producer to be visible. This makes IR transformation harder/brittle, so I want to update FIR to get rid if this. Codegen/printer/parser of fir.coordinate_of and many tests need to be updated after this change.
2025-02-28 09:50:05 +01:00
if (shapeAnalysis->hasKnownShape) {
[mlir][flang] Make use of the new `GEPArg` builder of GEP Op to simplify code This is the follow up on https://reviews.llvm.org/D130730 which goes through upstream code and removes creating constant values in favour of using the constant indices in GEP directly. This leads to less and more readable code and more compact IR as well. Differential Revision: https://reviews.llvm.org/D130731
2022-07-29 01:00:22 +02:00
offs.push_back(0);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
[flang] update fir.coordinate_of to carry the fields (#127231) This patch updates fir.coordinate_op to carry the field index as attributes instead of relying on getting it from the fir.field_index operations defining its operands. The rational is that FIR currently has a few operations that require DAGs to be preserved in order to be able to do code generation. This is the case of fir.coordinate_op, which requires its fir.field operand producer to be visible. This makes IR transformation harder/brittle, so I want to update FIR to get rid if this. Codegen/printer/parser of fir.coordinate_of and many tests need to be updated after this change.
2025-02-28 09:50:05 +01:00
// Else, only the column is `?` and we can simply place the column value
// in the 0-th GEP position.
mlir/tblgen: use std::optional in generation This is part of an effort to migrate from llvm::Optional to std::optional. This patch changes the way mlir-tblgen generates .inc files, and modifies tests and documentation appropriately. It is a "no compromises" patch, and doesn't leave the user with an unpleasant mix of llvm::Optional and std::optional. A non-trivial change has been made to ControlFlowInterfaces to split one constructor into two, relating to a build failure on Windows. See also: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 Signed-off-by: Ramkumar Ramachandra <r@artagnon.com> Differential Revision: https://reviews.llvm.org/D138934
2022-12-14 11:39:19 +01:00
std::optional<int> dims;
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
llvm::SmallVector<mlir::Value> arrIdx;
[flang] update fir.coordinate_of to carry the fields (#127231) This patch updates fir.coordinate_op to carry the field index as attributes instead of relying on getting it from the fir.field_index operations defining its operands. The rational is that FIR currently has a few operations that require DAGs to be preserved in order to be able to do code generation. This is the case of fir.coordinate_op, which requires its fir.field operand producer to be visible. This makes IR transformation harder/brittle, so I want to update FIR to get rid if this. Codegen/printer/parser of fir.coordinate_of and many tests need to be updated after this change.
2025-02-28 09:50:05 +01:00
int nextIndexValue = 1;
for (auto index : coor.getIndices()) {
if (auto intAttr = llvm::dyn_cast<mlir::IntegerAttr>(index)) {
// Addressing derived type component.
auto recordType = llvm::dyn_cast<fir::RecordType>(cpnTy);
if (!recordType)
return mlir::emitError(
loc,
"fir.coordinate base type is not consistent with operands");
int fieldId = intAttr.getInt();
cpnTy = recordType.getType(fieldId);
offs.push_back(fieldId);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
continue;
}
[flang] update fir.coordinate_of to carry the fields (#127231) This patch updates fir.coordinate_op to carry the field index as attributes instead of relying on getting it from the fir.field_index operations defining its operands. The rational is that FIR currently has a few operations that require DAGs to be preserved in order to be able to do code generation. This is the case of fir.coordinate_op, which requires its fir.field operand producer to be visible. This makes IR transformation harder/brittle, so I want to update FIR to get rid if this. Codegen/printer/parser of fir.coordinate_of and many tests need to be updated after this change.
2025-02-28 09:50:05 +01:00
// Value index (addressing array, tuple, or complex part).
mlir::Value indexValue = operands[nextIndexValue++];
if (auto tupTy = mlir::dyn_cast<mlir::TupleType>(cpnTy)) {
cpnTy = tupTy.getType(getConstantIntValue(indexValue));
offs.push_back(indexValue);
} else {
if (!dims) {
if (auto arrayType = llvm::dyn_cast<fir::SequenceType>(cpnTy)) {
// Starting addressing array or array component.
dims = arrayType.getDimension();
cpnTy = arrayType.getElementType();
}
}
if (dims) {
arrIdx.push_back(indexValue);
if (--(*dims) == 0) {
// Append array range in reverse (FIR arrays are column-major).
offs.append(arrIdx.rbegin(), arrIdx.rend());
arrIdx.clear();
dims.reset();
}
} else {
offs.push_back(indexValue);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
}
[fir] Add fircg.ext_array_coor conversion This patch adds the conversion pattern for the fircg.ext_array_coor operation. It applies the address arithmetic on a dynamically shaped, shifted and/or sliced array. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113968 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-06 15:51:45 +01:00
}
[flang] update fir.coordinate_of to carry the fields (#127231) This patch updates fir.coordinate_op to carry the field index as attributes instead of relying on getting it from the fir.field_index operations defining its operands. The rational is that FIR currently has a few operations that require DAGs to be preserved in order to be able to do code generation. This is the case of fir.coordinate_op, which requires its fir.field operand producer to be visible. This makes IR transformation harder/brittle, so I want to update FIR to get rid if this. Codegen/printer/parser of fir.coordinate_of and many tests need to be updated after this change.
2025-02-28 09:50:05 +01:00
// It is possible the fir.coordinate_of result is a sub-array, in which
// case there may be some "unfinished" array indices to reverse and push.
if (!arrIdx.empty())
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
offs.append(arrIdx.rbegin(), arrIdx.rend());
[flang] update fir.coordinate_of to carry the fields (#127231) This patch updates fir.coordinate_op to carry the field index as attributes instead of relying on getting it from the fir.field_index operations defining its operands. The rational is that FIR currently has a few operations that require DAGs to be preserved in order to be able to do code generation. This is the case of fir.coordinate_op, which requires its fir.field operand producer to be visible. This makes IR transformation harder/brittle, so I want to update FIR to get rid if this. Codegen/printer/parser of fir.coordinate_of and many tests need to be updated after this change.
2025-02-28 09:50:05 +01:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::Value base = operands[0];
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::Value retval = genGEP(loc, llvmObjectTy, rewriter, base, offs);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
rewriter.replaceOp(coor, retval);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[fir] Add fircg.ext_array_coor conversion This patch adds the conversion pattern for the fircg.ext_array_coor operation. It applies the address arithmetic on a dynamically shaped, shifted and/or sliced array. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113968 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-06 15:51:45 +01:00
}
[flang] Update the conversion code for fir.coordinate_of These are mostly small changes to make the code a bit clearer and more consistent. Summary of changes: * add missing namespace qualifiers (that's the preference in Flang) * replace const member methods with static methods (to avoid passing the *this pointer unnecessarily) * rename `currentObjTy` (current object type) as `cpnTy` (component type) - the latter feels more fitting * remove redundant `return failure();` calls (` return mlir::emitError` gives the same result) * updated a few comments Differential Revision: https://reviews.llvm.org/D122799
2022-03-28 16:13:59 +00:00
return mlir::emitError(
loc, "fir.coordinate_of base operand has unsupported type");
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
};
/// Convert `fir.field_index`. The conversion depends on whether the size of
/// the record is static or dynamic.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct FieldIndexOpConversion : public fir::FIROpConversion<fir::FieldIndexOp> {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
using FIROpConversion::FIROpConversion;
// NB: most field references should be resolved by this point
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::FieldIndexOp field, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
auto recTy = mlir::cast<fir::RecordType>(field.getOnType());
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
unsigned index = recTy.getFieldIndex(field.getFieldId());
if (!fir::hasDynamicSize(recTy)) {
// Derived type has compile-time constant layout. Return index of the
// component type in the parent type (to be used in GEP).
rewriter.replaceOp(field, mlir::ValueRange{genConstantOffset(
field.getLoc(), rewriter, index)});
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[fir] Add fircg.ext_array_coor conversion This patch adds the conversion pattern for the fircg.ext_array_coor operation. It applies the address arithmetic on a dynamically shaped, shifted and/or sliced array. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113968 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-06 15:51:45 +01:00
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// Derived type has compile-time constant layout. Call the compiler
// generated function to determine the byte offset of the field at runtime.
// This returns a non-constant.
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
mlir::FlatSymbolRefAttr symAttr = mlir::SymbolRefAttr::get(
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
field.getContext(), getOffsetMethodName(recTy, field.getFieldId()));
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
mlir::NamedAttribute callAttr = rewriter.getNamedAttr("callee", symAttr);
mlir::NamedAttribute fieldAttr = rewriter.getNamedAttr(
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
"field", mlir::IntegerAttr::get(lowerTy().indexType(), index));
rewriter.replaceOpWithNewOp<mlir::LLVM::CallOp>(
field, lowerTy().offsetType(), adaptor.getOperands(),
[mlir][LLVM] Add operand bundle support (#108933) This PR adds LLVM [operand bundle](https://llvm.org/docs/LangRef.html#operand-bundles) support to MLIR LLVM dialect. It affects these 3 operations related to making function calls: `llvm.call`, `llvm.invoke`, and `llvm.call_intrinsic`. This PR adds two new parameters to each of the 3 operations. The first parameter is a variadic operand `op_bundle_operands` that contains the SSA values for operand bundles. The second parameter is a property `op_bundle_tags` which holds an array of strings that represent the tags of each operand bundle.
2024-09-26 13:59:37 +08:00
addLLVMOpBundleAttrs(rewriter, {callAttr, fieldAttr},
adaptor.getOperands().size()));
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[fir] Add fircg.ext_array_coor conversion This patch adds the conversion pattern for the fircg.ext_array_coor operation. It applies the address arithmetic on a dynamically shaped, shifted and/or sliced array. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113968 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-06 15:51:45 +01:00
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// Re-Construct the name of the compiler generated method that calculates the
// offset
inline static std::string getOffsetMethodName(fir::RecordType recTy,
llvm::StringRef field) {
return recTy.getName().str() + "P." + field.str() + ".offset";
}
[fir] Add fircg.ext_array_coor conversion This patch adds the conversion pattern for the fircg.ext_array_coor operation. It applies the address arithmetic on a dynamically shaped, shifted and/or sliced array. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113968 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-12-06 15:51:45 +01:00
};
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// Convert `fir.end`
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct FirEndOpConversion : public fir::FIROpConversion<fir::FirEndOp> {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
using FIROpConversion::FIROpConversion;
[fir] Add complex operations conversion from FIR LLVM IR This patch add conversion for primitive operations on complex types. - fir.addc - fir.subc - fir.mulc - fir.divc - fir.negc This adds also the type conversion for !fir.complex<KIND> type. This patch is part of the upstreaming effort from fir-dev branch. This patch was updated to avoid failure on windows buildbot. Flang codegen does not support windows target so we force the test to use a known target instead. Reviewed By: kiranchandramohan, rovka Differential Revision: https://reviews.llvm.org/D113434 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 14:15:07 +01:00
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::FirEndOp firEnd, OpAdaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
TODO(firEnd.getLoc(), "fir.end codegen");
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::failure();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
};
[fir] Add complex operations conversion from FIR LLVM IR This patch add conversion for primitive operations on complex types. - fir.addc - fir.subc - fir.mulc - fir.divc - fir.negc This adds also the type conversion for !fir.complex<KIND> type. This patch is part of the upstreaming effort from fir-dev branch. This patch was updated to avoid failure on windows buildbot. Flang codegen does not support windows target so we force the test to use a known target instead. Reviewed By: kiranchandramohan, rovka Differential Revision: https://reviews.llvm.org/D113434 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 14:15:07 +01:00
[flang] Use fir.type_desc and delay type desc address resolution Makes use of fir.type_desc in order to delay the type desc address resolution. The lowering inserts fir.type_desc operation instead of fir.addr_of operation pointing to the fir.global type descriptor. The fir.type_desc operation is then lowered in code gen to an address of operation in the LLVM dialect. At this stage, the type descriptor is generated in all cases. Reviewed By: vdonaldson Differential Revision: https://reviews.llvm.org/D142920
2023-01-31 20:09:56 +01:00
/// Lower `fir.type_desc` to a global addr.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct TypeDescOpConversion : public fir::FIROpConversion<fir::TypeDescOp> {
[fir] Add complex operations conversion from FIR LLVM IR This patch add conversion for primitive operations on complex types. - fir.addc - fir.subc - fir.mulc - fir.divc - fir.negc This adds also the type conversion for !fir.complex<KIND> type. This patch is part of the upstreaming effort from fir-dev branch. This patch was updated to avoid failure on windows buildbot. Flang codegen does not support windows target so we force the test to use a known target instead. Reviewed By: kiranchandramohan, rovka Differential Revision: https://reviews.llvm.org/D113434 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 14:15:07 +01:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[flang] Use fir.type_desc and delay type desc address resolution Makes use of fir.type_desc in order to delay the type desc address resolution. The lowering inserts fir.type_desc operation instead of fir.addr_of operation pointing to the fir.global type descriptor. The fir.type_desc operation is then lowered in code gen to an address of operation in the LLVM dialect. At this stage, the type descriptor is generated in all cases. Reviewed By: vdonaldson Differential Revision: https://reviews.llvm.org/D142920
2023-01-31 20:09:56 +01:00
matchAndRewrite(fir::TypeDescOp typeDescOp, OpAdaptor adaptor,
[fir] Add complex operations conversion from FIR LLVM IR This patch add conversion for primitive operations on complex types. - fir.addc - fir.subc - fir.mulc - fir.divc - fir.negc This adds also the type conversion for !fir.complex<KIND> type. This patch is part of the upstreaming effort from fir-dev branch. This patch was updated to avoid failure on windows buildbot. Flang codegen does not support windows target so we force the test to use a known target instead. Reviewed By: kiranchandramohan, rovka Differential Revision: https://reviews.llvm.org/D113434 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 14:15:07 +01:00
mlir::ConversionPatternRewriter &rewriter) const override {
[flang] Use fir.type_desc and delay type desc address resolution Makes use of fir.type_desc in order to delay the type desc address resolution. The lowering inserts fir.type_desc operation instead of fir.addr_of operation pointing to the fir.global type descriptor. The fir.type_desc operation is then lowered in code gen to an address of operation in the LLVM dialect. At this stage, the type descriptor is generated in all cases. Reviewed By: vdonaldson Differential Revision: https://reviews.llvm.org/D142920
2023-01-31 20:09:56 +01:00
mlir::Type inTy = typeDescOp.getInType();
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
assert(mlir::isa<fir::RecordType>(inTy) && "expecting fir.type");
auto recordType = mlir::dyn_cast<fir::RecordType>(inTy);
[flang] Use fir.type_desc and delay type desc address resolution Makes use of fir.type_desc in order to delay the type desc address resolution. The lowering inserts fir.type_desc operation instead of fir.addr_of operation pointing to the fir.global type descriptor. The fir.type_desc operation is then lowered in code gen to an address of operation in the LLVM dialect. At this stage, the type descriptor is generated in all cases. Reviewed By: vdonaldson Differential Revision: https://reviews.llvm.org/D142920
2023-01-31 20:09:56 +01:00
auto module = typeDescOp.getOperation()->getParentOfType<mlir::ModuleOp>();
std::string typeDescName =
[RFC][flang] Replace special symbols in uniqued global names. (#104859) This change addresses more "issues" as the one resolved in #71338. Some targets (e.g. NVPTX) do not accept global names containing `.`. In particular, the global variables created to represent the runtime information of derived types use `.` in their names. A derived type's descriptor object may be used in the device code, e.g. to initialize a descriptor of a variable of this type. Thus, the runtime type info objects may need to be compiled for the device. Moreover, at least the derived types' descriptor objects may need to be registered (think of `omp declare target`) for the host-device association so that the addendum pointer can be properly mapped to the device for descriptors using a derived type's descriptor as their addendum pointer. The registration implies knowing the name of the global variable in the device image so that proper host code can be created. So it is better to name the globals the same way for the host and the device. CompilerGeneratedNamesConversion pass renames all uniqued globals such that the special symbols (currently `.`) are replaced with `X`. The pass is supposed to be run for the host and the device. An option is added to FIR-to-LLVM conversion pass to indicate whether the new pass has been run before or not. This setting affects how the codegen computes the names of the derived types' descriptors for FIR derived types. fir::NameUniquer now allows `X` to be part of a name, because the name deconstruction may be applied to the mangled names after CompilerGeneratedNamesConversion pass.
2024-08-21 13:37:03 -07:00
this->options.typeDescriptorsRenamedForAssembly
? fir::NameUniquer::getTypeDescriptorAssemblyName(
recordType.getName())
: fir::NameUniquer::getTypeDescriptorName(recordType.getName());
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
auto llvmPtrTy = ::getLlvmPtrType(typeDescOp.getContext());
[flang] Use fir.type_desc and delay type desc address resolution Makes use of fir.type_desc in order to delay the type desc address resolution. The lowering inserts fir.type_desc operation instead of fir.addr_of operation pointing to the fir.global type descriptor. The fir.type_desc operation is then lowered in code gen to an address of operation in the LLVM dialect. At this stage, the type descriptor is generated in all cases. Reviewed By: vdonaldson Differential Revision: https://reviews.llvm.org/D142920
2023-01-31 20:09:56 +01:00
if (auto global = module.lookupSymbol<mlir::LLVM::GlobalOp>(typeDescName)) {
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
rewriter.replaceOpWithNewOp<mlir::LLVM::AddressOfOp>(
typeDescOp, llvmPtrTy, global.getSymName());
[flang] Use fir.type_desc and delay type desc address resolution Makes use of fir.type_desc in order to delay the type desc address resolution. The lowering inserts fir.type_desc operation instead of fir.addr_of operation pointing to the fir.global type descriptor. The fir.type_desc operation is then lowered in code gen to an address of operation in the LLVM dialect. At this stage, the type descriptor is generated in all cases. Reviewed By: vdonaldson Differential Revision: https://reviews.llvm.org/D142920
2023-01-31 20:09:56 +01:00
return mlir::success();
} else if (auto global = module.lookupSymbol<fir::GlobalOp>(typeDescName)) {
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
rewriter.replaceOpWithNewOp<mlir::LLVM::AddressOfOp>(
typeDescOp, llvmPtrTy, global.getSymName());
[flang] Use fir.type_desc and delay type desc address resolution Makes use of fir.type_desc in order to delay the type desc address resolution. The lowering inserts fir.type_desc operation instead of fir.addr_of operation pointing to the fir.global type descriptor. The fir.type_desc operation is then lowered in code gen to an address of operation in the LLVM dialect. At this stage, the type descriptor is generated in all cases. Reviewed By: vdonaldson Differential Revision: https://reviews.llvm.org/D142920
2023-01-31 20:09:56 +01:00
return mlir::success();
}
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::failure();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
};
/// Lower `fir.has_value` operation to `llvm.return` operation.
[flang] Remove materialization workaround in type converter (#98743) This change is in preparation of #97903, which adds extra checks for materializations: it is now enforced that they produce an SSA value of the correct type, so the current workaround no longer works. The original workaround avoided target materializations by directly returning the to-be-converted SSA value from the materialization callback. This can be avoided by initializing the lowering patterns that insert the materializations without a type converter. For `cg::XEmboxOp`, the existing workaround that skips `unrealized_conversion_cast` ops is still in place. Also remove the lowering pattern for `unrealized_conversion_cast`. This pattern has no effect because `unrealized_conversion_cast` ops that are inserted by the dialect conversion framework are never matched by the pattern driver.
2024-07-15 16:07:48 +02:00
struct HasValueOpConversion
: public mlir::OpConversionPattern<fir::HasValueOp> {
using OpConversionPattern::OpConversionPattern;
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::HasValueOp op, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
rewriter.replaceOpWithNewOp<mlir::LLVM::ReturnOp>(op,
adaptor.getOperands());
return mlir::success();
[fir] Add complex operations conversion from FIR LLVM IR This patch add conversion for primitive operations on complex types. - fir.addc - fir.subc - fir.mulc - fir.divc - fir.negc This adds also the type conversion for !fir.complex<KIND> type. This patch is part of the upstreaming effort from fir-dev branch. This patch was updated to avoid failure on windows buildbot. Flang codegen does not support windows target so we force the test to use a known target instead. Reviewed By: kiranchandramohan, rovka Differential Revision: https://reviews.llvm.org/D113434 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 14:15:07 +01:00
}
};
[flang] Function 'attributeTypeIsCompatible' should be debug only (NFC) /data/home/jiefu/llvm-project/flang/lib/Optimizer/CodeGen/CodeGen.cpp:2905:20: error: unused function 'attributeTypeIsCompatible' [-Werror,-Wunused-function] static inline bool attributeTypeIsCompatible(mlir::MLIRContext *ctx, ^ 1 error generated.
2023-08-30 22:27:10 +08:00
#ifndef NDEBUG
[flang] Add support for dense complex constants Add support for representing complex array constants with MLIR dense attribute. This improves compile time and greatly reduces memory usage of programs with large complex array constants. Fixes https://github.com/llvm/llvm-project/issues/63610 Reviewed By: vzakhari Differential Revision: https://reviews.llvm.org/D155951
2023-08-30 10:49:37 -03:00
// Check if attr's type is compatible with ty.
//
// This is done by comparing attr's element type, converted to LLVM type,
// with ty's element type.
//
// Only integer and floating point (including complex) attributes are
// supported. Also, attr is expected to have a TensorType and ty is expected
// to be of LLVMArrayType. If any of the previous conditions is false, then
// the specified attr and ty are not supported by this function and are
// assumed to be compatible.
static inline bool attributeTypeIsCompatible(mlir::MLIRContext *ctx,
mlir::Attribute attr,
mlir::Type ty) {
// Get attr's LLVM element type.
if (!attr)
return true;
auto intOrFpEleAttr = mlir::dyn_cast<mlir::DenseIntOrFPElementsAttr>(attr);
if (!intOrFpEleAttr)
return true;
auto tensorTy = mlir::dyn_cast<mlir::TensorType>(intOrFpEleAttr.getType());
if (!tensorTy)
return true;
mlir::Type attrEleTy =
mlir::LLVMTypeConverter(ctx).convertType(tensorTy.getElementType());
// Get ty's element type.
auto arrTy = mlir::dyn_cast<mlir::LLVM::LLVMArrayType>(ty);
if (!arrTy)
return true;
mlir::Type eleTy = arrTy.getElementType();
while ((arrTy = mlir::dyn_cast<mlir::LLVM::LLVMArrayType>(eleTy)))
eleTy = arrTy.getElementType();
return attrEleTy == eleTy;
}
[flang] Function 'attributeTypeIsCompatible' should be debug only (NFC) /data/home/jiefu/llvm-project/flang/lib/Optimizer/CodeGen/CodeGen.cpp:2905:20: error: unused function 'attributeTypeIsCompatible' [-Werror,-Wunused-function] static inline bool attributeTypeIsCompatible(mlir::MLIRContext *ctx, ^ 1 error generated.
2023-08-30 22:27:10 +08:00
#endif
[flang] Add support for dense complex constants Add support for representing complex array constants with MLIR dense attribute. This improves compile time and greatly reduces memory usage of programs with large complex array constants. Fixes https://github.com/llvm/llvm-project/issues/63610 Reviewed By: vzakhari Differential Revision: https://reviews.llvm.org/D155951
2023-08-30 10:49:37 -03:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// Lower `fir.global` operation to `llvm.global` operation.
/// `fir.insert_on_range` operations are replaced with constant dense attribute
/// if they are applied on the full range.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct GlobalOpConversion : public fir::FIROpConversion<fir::GlobalOp> {
[fir] Add complex operations conversion from FIR LLVM IR This patch add conversion for primitive operations on complex types. - fir.addc - fir.subc - fir.mulc - fir.divc - fir.negc This adds also the type conversion for !fir.complex<KIND> type. This patch is part of the upstreaming effort from fir-dev branch. This patch was updated to avoid failure on windows buildbot. Flang codegen does not support windows target so we force the test to use a known target instead. Reviewed By: kiranchandramohan, rovka Differential Revision: https://reviews.llvm.org/D113434 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 14:15:07 +01:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::GlobalOp global, OpAdaptor adaptor,
[fir] Add complex operations conversion from FIR LLVM IR This patch add conversion for primitive operations on complex types. - fir.addc - fir.subc - fir.mulc - fir.divc - fir.negc This adds also the type conversion for !fir.complex<KIND> type. This patch is part of the upstreaming effort from fir-dev branch. This patch was updated to avoid failure on windows buildbot. Flang codegen does not support windows target so we force the test to use a known target instead. Reviewed By: kiranchandramohan, rovka Differential Revision: https://reviews.llvm.org/D113434 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 14:15:07 +01:00
mlir::ConversionPatternRewriter &rewriter) const override {
[flang] Add debug information for module variables. (#91582) This PR add debug info for module variables. The module variables are added as global variables but their scope is set to module instead of compile unit. The scope of function declared inside a module is also set accordingly. After this patch, a module variable could be evaluated in the GDB as `p helper::gli` where helper is name of the module and gli is the name of the variable. A future patch will add the import module functionality which will remove the need to prefix the name with helper::. The line number where is module is declared is a best guess at the moment as this information is not part of the GlobalOp.
2024-05-22 10:59:29 +01:00
[mlir][debug] Allow multiple DIGlobalVariableExpression on globals. (#111981) Currently, we allow only one DIGlobalVariableExpressionAttr per global. It is especially evident in import where we pick the first from the list and ignore the rest. In contrast, LLVM allows multiple DIGlobalVariableExpression to be attached to the global. They are needed for correct working of things like DICommonBlock. This PR removes this restriction in mlir. Changes are mostly mechanical. One thing on which I went a bit back and forth was the representation inside GlobalOp. I would be happy to change if there are better ways to do this. --------- Co-authored-by: Tobias Gysi <tobias.gysi@nextsilicon.com>
2024-10-13 23:36:00 +01:00
llvm::SmallVector<mlir::Attribute> dbgExprs;
[flang] Add debug information for module variables. (#91582) This PR add debug info for module variables. The module variables are added as global variables but their scope is set to module instead of compile unit. The scope of function declared inside a module is also set accordingly. After this patch, a module variable could be evaluated in the GDB as `p helper::gli` where helper is name of the module and gli is the name of the variable. A future patch will add the import module functionality which will remove the need to prefix the name with helper::. The line number where is module is declared is a best guess at the moment as this information is not part of the GlobalOp.
2024-05-22 10:59:29 +01:00
if (auto fusedLoc = mlir::dyn_cast<mlir::FusedLoc>(global.getLoc())) {
[flang][debug] Add support for common blocks. (#112398) This PR adds debug support for common block in flang. As variable which are part of a common block don't have a special marker to recognize them, we use the following check to find them. %0 = fir.address_of(@a) %1 = fir.convert %0 %2 = fir.coordinate_of %1, %c0 %3 = fir.convert %2 %4 = fircg.ext_declare %3 If the memref of a fircg.ext_declare points to a fir.coordinate_of and that in turn points to an fir.address_of (ignoring immediate fir.convert) then we assume that it is a common block variable. The fir.address_of gives us the global symbol which is the storage for common block and fir.coordinate_of provides the offset in this storage. The debug hierarchy looks like as subroutine f3 integer :: x, y common /a/ x, y end subroutine @a_ = global { ... } { ... }, !dbg !26, !dbg !28 !23 = !DISubprogram(name: "f3"...) !24 = !DICommonBlock(scope: !23, name: "a", ...) !25 = !DIGlobalVariable(name: "x", scope: !24 ...) !26 = !DIGlobalVariableExpression(var: !25, expr: !DIExpression()) !27 = !DIGlobalVariable(name: "y", scope: !24 ...) !28 = !DIGlobalVariableExpression(var: !27, expr: !DIExpression(DW_OP_plus_uconst, 4)) This required following changes: 1. Instead of using DIGlobalVariableAttr in the FusedLoc of GlobalOp, we use DIGlobalVariableExpressionAttr. This allows us the generate the DIExpression where we have the information. 2. Previously, only one DIGlobalVariableExpressionAttr could be linked to one global op. I recently removed this restriction in mlir. To make use of it, we add an ArrayAttr to the FusedLoc of a GlobalOp. This allows us to pass multiple DIGlobalVariableExpressionAttr. 3. I was depending on the name of global for the name of the common block. The name gets a '_' appended. I could not find a utility function in flang to remove it so I have to brute force it.
2025-01-28 12:54:15 +00:00
if (auto gvExprAttr = mlir::dyn_cast_if_present<mlir::ArrayAttr>(
fusedLoc.getMetadata())) {
for (auto attr : gvExprAttr.getAsRange<mlir::Attribute>())
if (auto dbgAttr =
mlir::dyn_cast<mlir::LLVM::DIGlobalVariableExpressionAttr>(
attr))
dbgExprs.push_back(dbgAttr);
[flang] Add debug information for module variables. (#91582) This PR add debug info for module variables. The module variables are added as global variables but their scope is set to module instead of compile unit. The scope of function declared inside a module is also set accordingly. After this patch, a module variable could be evaluated in the GDB as `p helper::gli` where helper is name of the module and gli is the name of the variable. A future patch will add the import module functionality which will remove the need to prefix the name with helper::. The line number where is module is declared is a best guess at the moment as this information is not part of the GlobalOp.
2024-05-22 10:59:29 +01:00
}
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
auto tyAttr = convertType(global.getType());
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
if (auto boxType = mlir::dyn_cast<fir::BaseBoxType>(global.getType()))
tyAttr = this->lowerTy().convertBoxTypeAsStruct(boxType);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
auto loc = global.getLoc();
[flang] Use value_or (NFC)
2022-07-16 00:51:54 -07:00
mlir::Attribute initAttr = global.getInitVal().value_or(mlir::Attribute());
[flang] Add support for dense complex constants Add support for representing complex array constants with MLIR dense attribute. This improves compile time and greatly reduces memory usage of programs with large complex array constants. Fixes https://github.com/llvm/llvm-project/issues/63610 Reviewed By: vzakhari Differential Revision: https://reviews.llvm.org/D155951
2023-08-30 10:49:37 -03:00
assert(attributeTypeIsCompatible(global.getContext(), initAttr, tyAttr));
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
auto linkage = convertLinkage(global.getLinkName());
[flang] Use has_value instead of hasValue (NFC) This patch replaces hasValue with has_value in an effort to deprecate Optional<X>::hasValue. Differential Revision: https://reviews.llvm.org/D129458
2022-07-11 20:41:12 -07:00
auto isConst = global.getConstant().has_value();
[flang] Add debug information for module variables. (#91582) This PR add debug info for module variables. The module variables are added as global variables but their scope is set to module instead of compile unit. The scope of function declared inside a module is also set accordingly. After this patch, a module variable could be evaluated in the GDB as `p helper::gli` where helper is name of the module and gli is the name of the variable. A future patch will add the import module functionality which will remove the need to prefix the name with helper::. The line number where is module is declared is a best guess at the moment as this information is not part of the GlobalOp.
2024-05-22 10:59:29 +01:00
mlir::SymbolRefAttr comdat;
llvm::ArrayRef<mlir::NamedAttribute> attrs;
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
auto g = rewriter.create<mlir::LLVM::GlobalOp>(
[flang] Add debug information for module variables. (#91582) This PR add debug info for module variables. The module variables are added as global variables but their scope is set to module instead of compile unit. The scope of function declared inside a module is also set accordingly. After this patch, a module variable could be evaluated in the GDB as `p helper::gli` where helper is name of the module and gli is the name of the variable. A future patch will add the import module functionality which will remove the need to prefix the name with helper::. The line number where is module is declared is a best guess at the moment as this information is not part of the GlobalOp.
2024-05-22 10:59:29 +01:00
loc, tyAttr, isConst, linkage, global.getSymName(), initAttr, 0, 0,
[mlir][debug] Allow multiple DIGlobalVariableExpression on globals. (#111981) Currently, we allow only one DIGlobalVariableExpressionAttr per global. It is especially evident in import where we pick the first from the list and ignore the rest. In contrast, LLVM allows multiple DIGlobalVariableExpression to be attached to the global. They are needed for correct working of things like DICommonBlock. This PR removes this restriction in mlir. Changes are mostly mechanical. One thing on which I went a bit back and forth was the representation inside GlobalOp. I would be happy to change if there are better ways to do this. --------- Co-authored-by: Tobias Gysi <tobias.gysi@nextsilicon.com>
2024-10-13 23:36:00 +01:00
false, false, comdat, attrs, dbgExprs);
[Flang][MLIR] Alter Fir.GlobalOp to print and lower external attributes Fir.GlobalOp's currently do not respect attributes that are applied to them, this change will do two things: - Allow lowering of arbitrary attributes applied to Fir.GlobalOp's to LLVMGlobalOp's during CodeGen - Allow printing and parsing of arbitrarily applied attributes This allows applying other dialects attributes (or other fir attributes) to fir.GlobalOps on the fly and have them exist in the resulting LLVM dialect IR or FIR IR. Reviewer: jeanPerier Differential Revision: https://reviews.llvm.org/D148352
2023-04-20 07:05:17 -05:00
[flang] Carry over alignment computed by frontend for COMMON (#94280) The frontend computes the necessary alignment for COMMON blocks but this information is never carried over to the code generation and can lead to segfault for COMMON block that requires a non default alignment. This patch add an optional attribute on fir.global and carries over the information.
2024-06-04 11:15:31 -07:00
if (global.getAlignment() && *global.getAlignment() > 0)
g.setAlignment(*global.getAlignment());
[flang] Add COMDAT to global variables where needed On platforms which support COMDAT sections we should use them when linkonce or linkonce_odr linkage is requested. This is required on Windows (PE/COFF) and provides better behaviour than weak symbols on ELF-based platforms. This patch also reverts string literals to use linkonce instead of internal linkage now that comdats are supported. Differential Revision: https://reviews.llvm.org/D153768
2023-06-26 15:03:17 +01:00
auto module = global->getParentOfType<mlir::ModuleOp>();
[flang][cuda] Make default.nonTbpDefinedIoTable compiler generated (#120686) `default.nonTbpDefinedIoTable` is a special global defined for IO that doesn't follow the mangling scheme and is then not handle correctly in the `CompilerGeneratedNames` pass. Update how it is generated with doGenerated so it can be handle without special handling. Also do not generate comdat in gpu module as the current code is not handling nested module correctly.
2024-12-20 10:37:48 -08:00
auto gpuMod = global->getParentOfType<mlir::gpu::GPUModuleOp>();
[flang] Add COMDAT to global variables where needed On platforms which support COMDAT sections we should use them when linkonce or linkonce_odr linkage is requested. This is required on Windows (PE/COFF) and provides better behaviour than weak symbols on ELF-based platforms. This patch also reverts string literals to use linkonce instead of internal linkage now that comdats are supported. Differential Revision: https://reviews.llvm.org/D153768
2023-06-26 15:03:17 +01:00
// Add comdat if necessary
if (fir::getTargetTriple(module).supportsCOMDAT() &&
(linkage == mlir::LLVM::Linkage::Linkonce ||
[flang][cuda] Make default.nonTbpDefinedIoTable compiler generated (#120686) `default.nonTbpDefinedIoTable` is a special global defined for IO that doesn't follow the mangling scheme and is then not handle correctly in the `CompilerGeneratedNames` pass. Update how it is generated with doGenerated so it can be handle without special handling. Also do not generate comdat in gpu module as the current code is not handling nested module correctly.
2024-12-20 10:37:48 -08:00
linkage == mlir::LLVM::Linkage::LinkonceODR) &&
!gpuMod) {
[flang] Add COMDAT to global variables where needed On platforms which support COMDAT sections we should use them when linkonce or linkonce_odr linkage is requested. This is required on Windows (PE/COFF) and provides better behaviour than weak symbols on ELF-based platforms. This patch also reverts string literals to use linkonce instead of internal linkage now that comdats are supported. Differential Revision: https://reviews.llvm.org/D153768
2023-06-26 15:03:17 +01:00
addComdat(g, rewriter, module);
}
[Flang][MLIR] Alter Fir.GlobalOp to print and lower external attributes Fir.GlobalOp's currently do not respect attributes that are applied to them, this change will do two things: - Allow lowering of arbitrary attributes applied to Fir.GlobalOp's to LLVMGlobalOp's during CodeGen - Allow printing and parsing of arbitrarily applied attributes This allows applying other dialects attributes (or other fir attributes) to fir.GlobalOps on the fly and have them exist in the resulting LLVM dialect IR or FIR IR. Reviewer: jeanPerier Differential Revision: https://reviews.llvm.org/D148352
2023-04-20 07:05:17 -05:00
// Apply all non-Fir::GlobalOp attributes to the LLVM::GlobalOp, preserving
// them; whilst taking care not to apply attributes that are lowered in
// other ways.
llvm::SmallDenseSet<llvm::StringRef> elidedAttrsSet(
global.getAttributeNames().begin(), global.getAttributeNames().end());
for (auto &attr : global->getAttrs())
if (!elidedAttrsSet.contains(attr.getName().strref()))
g->setAttr(attr.getName(), attr.getValue());
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
auto &gr = g.getInitializerRegion();
rewriter.inlineRegionBefore(global.getRegion(), gr, gr.end());
if (!gr.empty()) {
// Replace insert_on_range with a constant dense attribute if the
// initialization is on the full range.
auto insertOnRangeOps = gr.front().getOps<fir::InsertOnRangeOp>();
for (auto insertOp : insertOnRangeOps) {
if (isFullRange(insertOp.getCoor(), insertOp.getType())) {
auto seqTyAttr = convertType(insertOp.getType());
auto *op = insertOp.getVal().getDefiningOp();
auto constant = mlir::dyn_cast<mlir::arith::ConstantOp>(op);
if (!constant) {
auto convertOp = mlir::dyn_cast<fir::ConvertOp>(op);
if (!convertOp)
continue;
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
constant = mlir::cast<mlir::arith::ConstantOp>(
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
convertOp.getValue().getDefiningOp());
}
mlir::Type vecType = mlir::VectorType::get(
insertOp.getType().getShape(), constant.getType());
auto denseAttr = mlir::DenseElementsAttr::get(
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
mlir::cast<mlir::ShapedType>(vecType), constant.getValue());
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
rewriter.setInsertionPointAfter(insertOp);
rewriter.replaceOpWithNewOp<mlir::arith::ConstantOp>(
insertOp, seqTyAttr, denseAttr);
}
}
}
[flang][cuda] Lower shared global to the correct NVVM address space (#131368) Global with the CUDA shared data attribute needs to be lowered to llvm globals with the correct address space (3). Address space is set from the `mlir::NVVM::NVVMMemorySpace::kSharedMemorySpace` enum from `mlir/Dialect/LLVMIR/NVVMDialect.h`
2025-03-14 15:28:32 -07:00
if (global.getDataAttr() &&
*global.getDataAttr() == cuf::DataAttribute::Shared)
g.setAddrSpace(mlir::NVVM::NVVMMemorySpace::kSharedMemorySpace);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
rewriter.eraseOp(global);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[fir] Add complex operations conversion from FIR LLVM IR This patch add conversion for primitive operations on complex types. - fir.addc - fir.subc - fir.mulc - fir.divc - fir.negc This adds also the type conversion for !fir.complex<KIND> type. This patch is part of the upstreaming effort from fir-dev branch. This patch was updated to avoid failure on windows buildbot. Flang codegen does not support windows target so we force the test to use a known target instead. Reviewed By: kiranchandramohan, rovka Differential Revision: https://reviews.llvm.org/D113434 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 14:15:07 +01:00
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
bool isFullRange(mlir::DenseIntElementsAttr indexes,
fir::SequenceType seqTy) const {
auto extents = seqTy.getShape();
if (indexes.size() / 2 != static_cast<int64_t>(extents.size()))
return false;
auto cur_index = indexes.value_begin<int64_t>();
for (unsigned i = 0; i < indexes.size(); i += 2) {
if (*(cur_index++) != 0)
return false;
if (*(cur_index++) != extents[i / 2] - 1)
return false;
}
return true;
}
[fir] Add complex operations conversion from FIR LLVM IR This patch add conversion for primitive operations on complex types. - fir.addc - fir.subc - fir.mulc - fir.divc - fir.negc This adds also the type conversion for !fir.complex<KIND> type. This patch is part of the upstreaming effort from fir-dev branch. This patch was updated to avoid failure on windows buildbot. Flang codegen does not support windows target so we force the test to use a known target instead. Reviewed By: kiranchandramohan, rovka Differential Revision: https://reviews.llvm.org/D113434 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 14:15:07 +01:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// TODO: String comparaison should be avoided. Replace linkName with an
// enumeration.
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
mlir::LLVM::Linkage
mlir/tblgen: use std::optional in generation This is part of an effort to migrate from llvm::Optional to std::optional. This patch changes the way mlir-tblgen generates .inc files, and modifies tests and documentation appropriately. It is a "no compromises" patch, and doesn't leave the user with an unpleasant mix of llvm::Optional and std::optional. A non-trivial change has been made to ControlFlowInterfaces to split one constructor into two, relating to a build failure on Windows. See also: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 Signed-off-by: Ramkumar Ramachandra <r@artagnon.com> Differential Revision: https://reviews.llvm.org/D138934
2022-12-14 11:39:19 +01:00
convertLinkage(std::optional<llvm::StringRef> optLinkage) const {
[flang] Don't use Optional::hasValue (NFC) Flang C++ Style Guide tells us to avoid .has_value() in the predicate expressions of control flow statements. I am treating ternary expressions as control flow statements for the purpose of this patch. Differential Revision: https://reviews.llvm.org/D128622
2022-07-10 15:01:06 -07:00
if (optLinkage) {
[flang] Use *X instead of X.getValue() (NFC) Per Flang C++ Style Guide, this patch replaces X.getValue() with *X where *X is protected by a presence test.
2022-07-16 00:24:02 -07:00
auto name = *optLinkage;
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
if (name == "internal")
return mlir::LLVM::Linkage::Internal;
if (name == "linkonce")
return mlir::LLVM::Linkage::Linkonce;
[flang] Add support for linkonce_odr in FIR Add support for parsing and converting linkonce_odr in FIR. Differential Revision: https://reviews.llvm.org/D121471
2022-03-14 10:24:17 +01:00
if (name == "linkonce_odr")
return mlir::LLVM::Linkage::LinkonceODR;
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
if (name == "common")
return mlir::LLVM::Linkage::Common;
if (name == "weak")
return mlir::LLVM::Linkage::Weak;
}
return mlir::LLVM::Linkage::External;
[fir] Add complex operations conversion from FIR LLVM IR This patch add conversion for primitive operations on complex types. - fir.addc - fir.subc - fir.mulc - fir.divc - fir.negc This adds also the type conversion for !fir.complex<KIND> type. This patch is part of the upstreaming effort from fir-dev branch. This patch was updated to avoid failure on windows buildbot. Flang codegen does not support windows target so we force the test to use a known target instead. Reviewed By: kiranchandramohan, rovka Differential Revision: https://reviews.llvm.org/D113434 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 14:15:07 +01:00
}
[flang] Add COMDAT to global variables where needed On platforms which support COMDAT sections we should use them when linkonce or linkonce_odr linkage is requested. This is required on Windows (PE/COFF) and provides better behaviour than weak symbols on ELF-based platforms. This patch also reverts string literals to use linkonce instead of internal linkage now that comdats are supported. Differential Revision: https://reviews.llvm.org/D153768
2023-06-26 15:03:17 +01:00
private:
static void addComdat(mlir::LLVM::GlobalOp &global,
mlir::ConversionPatternRewriter &rewriter,
[flang] Fix some memory leaks (#121050) This commit fixes some but not all memory leaks in Flang. There are still 91 tests that fail with ASAN. - Use `mlir::OwningOpRef` instead of `std::unique_ptr`. The latter does not free allocations of nested blocks. - Pass `ModuleOp` as value instead of reference. - Add few missing deallocations in test cases and other places.
2024-12-25 09:42:03 +01:00
mlir::ModuleOp module) {
[flang] Add COMDAT to global variables where needed On platforms which support COMDAT sections we should use them when linkonce or linkonce_odr linkage is requested. This is required on Windows (PE/COFF) and provides better behaviour than weak symbols on ELF-based platforms. This patch also reverts string literals to use linkonce instead of internal linkage now that comdats are supported. Differential Revision: https://reviews.llvm.org/D153768
2023-06-26 15:03:17 +01:00
const char *comdatName = "__llvm_comdat";
mlir::LLVM::ComdatOp comdatOp =
module.lookupSymbol<mlir::LLVM::ComdatOp>(comdatName);
if (!comdatOp) {
comdatOp =
rewriter.create<mlir::LLVM::ComdatOp>(module.getLoc(), comdatName);
}
[flang] Avoid generating duplicate symbol in comdat (#114472) In case where a fir.global might be duplicated in an inner module (gpu.module), the conversion pattern will be applied on the module and the gpu module version of the global and try to generate multiple comdat with the same symbol name. This is what we have in the implementation of CUDA Fortran. Just check for the presence of the `ComdatSelectorOp` before creating a new one.
2024-10-31 18:59:04 -07:00
if (auto select = comdatOp.lookupSymbol<mlir::LLVM::ComdatSelectorOp>(
global.getSymName()))
return;
[flang] Add COMDAT to global variables where needed On platforms which support COMDAT sections we should use them when linkonce or linkonce_odr linkage is requested. This is required on Windows (PE/COFF) and provides better behaviour than weak symbols on ELF-based platforms. This patch also reverts string literals to use linkonce instead of internal linkage now that comdats are supported. Differential Revision: https://reviews.llvm.org/D153768
2023-06-26 15:03:17 +01:00
mlir::OpBuilder::InsertionGuard guard(rewriter);
rewriter.setInsertionPointToEnd(&comdatOp.getBody().back());
auto selectorOp = rewriter.create<mlir::LLVM::ComdatSelectorOp>(
comdatOp.getLoc(), global.getSymName(),
mlir::LLVM::comdat::Comdat::Any);
global.setComdatAttr(mlir::SymbolRefAttr::get(
rewriter.getContext(), comdatName,
mlir::FlatSymbolRefAttr::get(selectorOp.getSymNameAttr())));
}
[fir] Add complex operations conversion from FIR LLVM IR This patch add conversion for primitive operations on complex types. - fir.addc - fir.subc - fir.mulc - fir.divc - fir.negc This adds also the type conversion for !fir.complex<KIND> type. This patch is part of the upstreaming effort from fir-dev branch. This patch was updated to avoid failure on windows buildbot. Flang codegen does not support windows target so we force the test to use a known target instead. Reviewed By: kiranchandramohan, rovka Differential Revision: https://reviews.llvm.org/D113434 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 14:15:07 +01:00
};
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// `fir.load` --> `llvm.load`
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct LoadOpConversion : public fir::FIROpConversion<fir::LoadOp> {
[fir] Add complex operations conversion from FIR LLVM IR This patch add conversion for primitive operations on complex types. - fir.addc - fir.subc - fir.mulc - fir.divc - fir.negc This adds also the type conversion for !fir.complex<KIND> type. This patch is part of the upstreaming effort from fir-dev branch. This patch was updated to avoid failure on windows buildbot. Flang codegen does not support windows target so we force the test to use a known target instead. Reviewed By: kiranchandramohan, rovka Differential Revision: https://reviews.llvm.org/D113434 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 14:15:07 +01:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::LoadOp load, OpAdaptor adaptor,
[fir] Add complex operations conversion from FIR LLVM IR This patch add conversion for primitive operations on complex types. - fir.addc - fir.subc - fir.mulc - fir.divc - fir.negc This adds also the type conversion for !fir.complex<KIND> type. This patch is part of the upstreaming effort from fir-dev branch. This patch was updated to avoid failure on windows buildbot. Flang codegen does not support windows target so we force the test to use a known target instead. Reviewed By: kiranchandramohan, rovka Differential Revision: https://reviews.llvm.org/D113434 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 14:15:07 +01:00
mlir::ConversionPatternRewriter &rewriter) const override {
[flang][fir] always use memcpy for fir.box (#113949) @jeanPerier explained the importance of converting box loads and stores into `memcpy`s instead of aggregate loads and stores, and I'll do my best to explain it here. * [(godbolt link) Example comparing opt transformations on memcpys vs aggregate load/stores](https://godbolt.org/z/be7xM83cG) * LLVM can more effectively reason about memcpys compared to aggregate load/stores. * This came up when others were discussing array descriptors for assumed-rank arrays passed to `bind(c)` subroutines, with the implication that the array descriptors are known to have lower bounds of 1 and that they are not pointer/allocatable types. * [(godbolt link) Clang also uses memcpys so we should probably follow them, assuming the clang developers are generatign what they know Opt will handle more effectively.](https://godbolt.org/z/YT4x7387W) * This currently may not help much without the `nocapture` attribute being propagated to function calls, but [it looks like someone may do this soon (discourse link)](https://discourse.llvm.org/t/applying-the-nocapture-attribute-to-reference-passed-arguments-in-fortran-subroutines/81401/23) or I can do this in a follow-up patch. Note on test `flang/test/Fir/embox-char.fir`: it looks like the original test was auto-generated. I wasn't too sure which parts were especially important to test, so I regenerated the test. If we want the updated version to look more like the old version, I'll make those changes.
2024-10-30 09:50:27 -07:00
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::Type llvmLoadTy = convertObjectType(load.getType());
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (auto boxTy = mlir::dyn_cast<fir::BaseBoxType>(load.getType())) {
[flang][fir] always use memcpy for fir.box (#113949) @jeanPerier explained the importance of converting box loads and stores into `memcpy`s instead of aggregate loads and stores, and I'll do my best to explain it here. * [(godbolt link) Example comparing opt transformations on memcpys vs aggregate load/stores](https://godbolt.org/z/be7xM83cG) * LLVM can more effectively reason about memcpys compared to aggregate load/stores. * This came up when others were discussing array descriptors for assumed-rank arrays passed to `bind(c)` subroutines, with the implication that the array descriptors are known to have lower bounds of 1 and that they are not pointer/allocatable types. * [(godbolt link) Clang also uses memcpys so we should probably follow them, assuming the clang developers are generatign what they know Opt will handle more effectively.](https://godbolt.org/z/YT4x7387W) * This currently may not help much without the `nocapture` attribute being propagated to function calls, but [it looks like someone may do this soon (discourse link)](https://discourse.llvm.org/t/applying-the-nocapture-attribute-to-reference-passed-arguments-in-fortran-subroutines/81401/23) or I can do this in a follow-up patch. Note on test `flang/test/Fir/embox-char.fir`: it looks like the original test was auto-generated. I wasn't too sure which parts were especially important to test, so I regenerated the test. If we want the updated version to look more like the old version, I'll make those changes.
2024-10-30 09:50:27 -07:00
// fir.box is a special case because it is considered an ssa value in
[flang] Make a descriptor copy for fir.load fir.ref<fir.box> `fir.box` and `fir.ref<fir.box>` are both lowered to LLVM as a descriptor in memory. This is because fir.box of polymorphic and assumed rank entities cannot be known at compile time, so fir.box cannot be lowered to a struct value. fir.load or fir.ref<fir.box> was previously lowered to a no-op, propagating the operand descriptor storage as a result. This is wrong because the operand descriptor storage may later be modified, and these changes should not be visible in the loaded fir.box that is an immutable SSA value. Modify fir.load codegen for fir.box to make a copy into a new storage to ensure the fir.box is immutable. Differential Revision: https://reviews.llvm.org/D133779
2022-09-14 08:54:00 +02:00
// fir, but it is lowered as a pointer to a descriptor. So
// fir.ref<fir.box> and fir.box end up being the same llvm types and
// loading a fir.ref<fir.box> is implemented as taking a snapshot of the
// descriptor value into a new descriptor temp.
auto inputBoxStorage = adaptor.getOperands()[0];
[flang][cuda] Correctly allocate memory for descriptor load (#120164) CodeGen will allocate memory for a new descriptor on descriptor loads. CUDA Fortran local descriptor are allocated in managed memory by the runtime. The newly allocated storage for cuda descriptor must also be allocated through the runtime.
2024-12-16 19:12:05 -08:00
mlir::Value newBoxStorage;
[flang] Make a descriptor copy for fir.load fir.ref<fir.box> `fir.box` and `fir.ref<fir.box>` are both lowered to LLVM as a descriptor in memory. This is because fir.box of polymorphic and assumed rank entities cannot be known at compile time, so fir.box cannot be lowered to a struct value. fir.load or fir.ref<fir.box> was previously lowered to a no-op, propagating the operand descriptor storage as a result. This is wrong because the operand descriptor storage may later be modified, and these changes should not be visible in the loaded fir.box that is an immutable SSA value. Modify fir.load codegen for fir.box to make a copy into a new storage to ensure the fir.box is immutable. Differential Revision: https://reviews.llvm.org/D133779
2022-09-14 08:54:00 +02:00
mlir::Location loc = load.getLoc();
[flang][cuda] Correctly allocate memory for descriptor load (#120164) CodeGen will allocate memory for a new descriptor on descriptor loads. CUDA Fortran local descriptor are allocated in managed memory by the runtime. The newly allocated storage for cuda descriptor must also be allocated through the runtime.
2024-12-16 19:12:05 -08:00
if (auto callOp = mlir::dyn_cast_or_null<mlir::LLVM::CallOp>(
inputBoxStorage.getDefiningOp())) {
if (callOp.getCallee() &&
(*callOp.getCallee())
[flang][cuda][NFC] Fix typo in CUFAllocDescriptor (#120797) Missing `r` in the function name.
2024-12-20 13:57:47 -08:00
.starts_with(RTNAME_STRING(CUFAllocDescriptor))) {
[flang][cuda] Correctly allocate memory for descriptor load (#120164) CodeGen will allocate memory for a new descriptor on descriptor loads. CUDA Fortran local descriptor are allocated in managed memory by the runtime. The newly allocated storage for cuda descriptor must also be allocated through the runtime.
2024-12-16 19:12:05 -08:00
// CUDA Fortran local descriptor are allocated in managed memory. So
// new storage must be allocated the same way.
auto mod = load->getParentOfType<mlir::ModuleOp>();
newBoxStorage =
genCUFAllocDescriptor(loc, rewriter, mod, boxTy, lowerTy());
}
}
if (!newBoxStorage)
newBoxStorage = genAllocaAndAddrCastWithType(loc, llvmLoadTy,
defaultAlign, rewriter);
[flang][fir] always use memcpy for fir.box (#113949) @jeanPerier explained the importance of converting box loads and stores into `memcpy`s instead of aggregate loads and stores, and I'll do my best to explain it here. * [(godbolt link) Example comparing opt transformations on memcpys vs aggregate load/stores](https://godbolt.org/z/be7xM83cG) * LLVM can more effectively reason about memcpys compared to aggregate load/stores. * This came up when others were discussing array descriptors for assumed-rank arrays passed to `bind(c)` subroutines, with the implication that the array descriptors are known to have lower bounds of 1 and that they are not pointer/allocatable types. * [(godbolt link) Clang also uses memcpys so we should probably follow them, assuming the clang developers are generatign what they know Opt will handle more effectively.](https://godbolt.org/z/YT4x7387W) * This currently may not help much without the `nocapture` attribute being propagated to function calls, but [it looks like someone may do this soon (discourse link)](https://discourse.llvm.org/t/applying-the-nocapture-attribute-to-reference-passed-arguments-in-fortran-subroutines/81401/23) or I can do this in a follow-up patch. Note on test `flang/test/Fir/embox-char.fir`: it looks like the original test was auto-generated. I wasn't too sure which parts were especially important to test, so I regenerated the test. If we want the updated version to look more like the old version, I'll make those changes.
2024-10-30 09:50:27 -07:00
TypePair boxTypePair{boxTy, llvmLoadTy};
mlir::Value boxSize =
computeBoxSize(loc, boxTypePair, inputBoxStorage, rewriter);
auto memcpy = rewriter.create<mlir::LLVM::MemcpyOp>(
loc, newBoxStorage, inputBoxStorage, boxSize, /*isVolatile=*/false);
if (std::optional<mlir::ArrayAttr> optionalTag = load.getTbaa())
memcpy.setTBAATags(*optionalTag);
else
attachTBAATag(memcpy, boxTy, boxTy, nullptr);
[Flang][MLIR] Add basic initial support for alloca and program address space handling in FIR->LLVMIR codegen (#77518) This is a slightly more slimmed down and up-to-date version of the older PR from here: https://reviews.llvm.org/D144203, written by @jsjodin, which has already under gone some review. This PR places allocas in the alloca address space specified by the provided data layout (default is 0 for all address spaces, unless explicitly specified by the layout), and then will cast these alloca's to the program address space if this address space is different from the allocation address space. For most architectures data layouts, this will be a no-op, as they have a flat address space. But in the case of AMDGPU it will result in allocas being placed in the correct address space (5, private), and then casted into the correct program address space (0, generic). This results in correct (partially, a follow up PR will be forthcoming soon) generation of allocations inside of device code. This PR is in addition to the work by @skatrak in this PR: https://github.com/llvm/llvm-project/pull/69599 and adds seperate and neccesary functionality of casting alloca's from their address space to the program address space, both are independent PRs, although there is some minor overlap e.g. this PR incorporates some of the useful helper functions from 69599, so whichever lands first will need a minor rebase. Co-author: jsjodin
2024-01-17 17:37:16 +01:00
rewriter.replaceOp(load, newBoxStorage);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
} else {
[flang] Generate TBAA information. This is initial version of TBAA information generation for Flang generated IR. The desired behavior is that TBAA type descriptors are generated for FIR types during FIR to LLVM types conversion, and then TBAA access tags are attached to memory accessing operations when they are converted to LLVM IR dialect. In the initial version the type conversion is not producing TBAA type descriptors, and all memory accesses are just partitioned into two sets of box and non-box accesses, which can never alias. The TBAA generation is enabled by default at >O0 optimization levels. TBAA generation may also be enabled via `apply-tbaa` option of `fir-to-llvm-ir` conversion pass. `-mllvm -disable-tbaa` engineering option allows disabling TBAA generation to override Flang's default (e.g. when -O1 is used). SPEC CPU2006/437.leslie3d speeds up by more than 2x on Icelake. Reviewed By: jeanPerier, clementval Differential Revision: https://reviews.llvm.org/D141820
2023-01-17 09:08:43 -08:00
auto loadOp = rewriter.create<mlir::LLVM::LoadOp>(
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
load.getLoc(), llvmLoadTy, adaptor.getOperands(), load->getAttrs());
[flang][FIR] add FirAliasAnalysisOpInterface (#68317) This interface allows (HL)FIR passes to add TBAA information to fir.load and fir.store. If present, these TBAA tags take precedence over those added during CodeGen. We can't reuse mlir::LLVMIR::AliasAnalysisOpInterface because that uses the mlir::LLVMIR namespace so it tries to define methods for fir operations in the wrong namespace. But I did re-use the tbaa tag type to minimise boilerplate code. The new builders are to preserve the old interface without the tbaa tag.
2023-10-11 15:06:50 +01:00
if (std::optional<mlir::ArrayAttr> optionalTag = load.getTbaa())
loadOp.setTBAATags(*optionalTag);
else
attachTBAATag(loadOp, load.getType(), load.getType(), nullptr);
[flang] Generate TBAA information. This is initial version of TBAA information generation for Flang generated IR. The desired behavior is that TBAA type descriptors are generated for FIR types during FIR to LLVM types conversion, and then TBAA access tags are attached to memory accessing operations when they are converted to LLVM IR dialect. In the initial version the type conversion is not producing TBAA type descriptors, and all memory accesses are just partitioned into two sets of box and non-box accesses, which can never alias. The TBAA generation is enabled by default at >O0 optimization levels. TBAA generation may also be enabled via `apply-tbaa` option of `fir-to-llvm-ir` conversion pass. `-mllvm -disable-tbaa` engineering option allows disabling TBAA generation to override Flang's default (e.g. when -O1 is used). SPEC CPU2006/437.leslie3d speeds up by more than 2x on Icelake. Reviewed By: jeanPerier, clementval Differential Revision: https://reviews.llvm.org/D141820
2023-01-17 09:08:43 -08:00
rewriter.replaceOp(load, loadOp.getResult());
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[fir] Add complex operations conversion from FIR LLVM IR This patch add conversion for primitive operations on complex types. - fir.addc - fir.subc - fir.mulc - fir.divc - fir.negc This adds also the type conversion for !fir.complex<KIND> type. This patch is part of the upstreaming effort from fir-dev branch. This patch was updated to avoid failure on windows buildbot. Flang codegen does not support windows target so we force the test to use a known target instead. Reviewed By: kiranchandramohan, rovka Differential Revision: https://reviews.llvm.org/D113434 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 14:15:07 +01:00
}
};
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// Lower `fir.no_reassoc` to LLVM IR dialect.
/// TODO: how do we want to enforce this in LLVM-IR? Can we manipulate the fast
/// math flags?
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct NoReassocOpConversion : public fir::FIROpConversion<fir::NoReassocOp> {
[fir] Add complex operations conversion from FIR LLVM IR This patch add conversion for primitive operations on complex types. - fir.addc - fir.subc - fir.mulc - fir.divc - fir.negc This adds also the type conversion for !fir.complex<KIND> type. This patch is part of the upstreaming effort from fir-dev branch. This patch was updated to avoid failure on windows buildbot. Flang codegen does not support windows target so we force the test to use a known target instead. Reviewed By: kiranchandramohan, rovka Differential Revision: https://reviews.llvm.org/D113434 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 14:15:07 +01:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::NoReassocOp noreassoc, OpAdaptor adaptor,
[fir] Add complex operations conversion from FIR LLVM IR This patch add conversion for primitive operations on complex types. - fir.addc - fir.subc - fir.mulc - fir.divc - fir.negc This adds also the type conversion for !fir.complex<KIND> type. This patch is part of the upstreaming effort from fir-dev branch. This patch was updated to avoid failure on windows buildbot. Flang codegen does not support windows target so we force the test to use a known target instead. Reviewed By: kiranchandramohan, rovka Differential Revision: https://reviews.llvm.org/D113434 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 14:15:07 +01:00
mlir::ConversionPatternRewriter &rewriter) const override {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
rewriter.replaceOp(noreassoc, adaptor.getOperands()[0]);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[fir] Add complex operations conversion from FIR LLVM IR This patch add conversion for primitive operations on complex types. - fir.addc - fir.subc - fir.mulc - fir.divc - fir.negc This adds also the type conversion for !fir.complex<KIND> type. This patch is part of the upstreaming effort from fir-dev branch. This patch was updated to avoid failure on windows buildbot. Flang codegen does not support windows target so we force the test to use a known target instead. Reviewed By: kiranchandramohan, rovka Differential Revision: https://reviews.llvm.org/D113434 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 14:15:07 +01:00
}
};
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
static void genCondBrOp(mlir::Location loc, mlir::Value cmp, mlir::Block *dest,
mlir/tblgen: use std::optional in generation This is part of an effort to migrate from llvm::Optional to std::optional. This patch changes the way mlir-tblgen generates .inc files, and modifies tests and documentation appropriately. It is a "no compromises" patch, and doesn't leave the user with an unpleasant mix of llvm::Optional and std::optional. A non-trivial change has been made to ControlFlowInterfaces to split one constructor into two, relating to a build failure on Windows. See also: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 Signed-off-by: Ramkumar Ramachandra <r@artagnon.com> Differential Revision: https://reviews.llvm.org/D138934
2022-12-14 11:39:19 +01:00
std::optional<mlir::ValueRange> destOps,
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::ConversionPatternRewriter &rewriter,
mlir::Block *newBlock) {
[flang] Don't use Optional::hasValue (NFC) Flang C++ Style Guide tells us to avoid .has_value() in the predicate expressions of control flow statements. I am treating ternary expressions as control flow statements for the purpose of this patch. Differential Revision: https://reviews.llvm.org/D128622
2022-07-10 15:01:06 -07:00
if (destOps)
[flang] Use *X instead of X.getValue() (NFC) Per Flang C++ Style Guide, this patch replaces X.getValue() with *X where *X is protected by a presence test.
2022-07-16 00:24:02 -07:00
rewriter.create<mlir::LLVM::CondBrOp>(loc, cmp, dest, *destOps, newBlock,
mlir::ValueRange());
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
else
rewriter.create<mlir::LLVM::CondBrOp>(loc, cmp, dest, newBlock);
}
template <typename A, typename B>
mlir/tblgen: use std::optional in generation This is part of an effort to migrate from llvm::Optional to std::optional. This patch changes the way mlir-tblgen generates .inc files, and modifies tests and documentation appropriately. It is a "no compromises" patch, and doesn't leave the user with an unpleasant mix of llvm::Optional and std::optional. A non-trivial change has been made to ControlFlowInterfaces to split one constructor into two, relating to a build failure on Windows. See also: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 Signed-off-by: Ramkumar Ramachandra <r@artagnon.com> Differential Revision: https://reviews.llvm.org/D138934
2022-12-14 11:39:19 +01:00
static void genBrOp(A caseOp, mlir::Block *dest, std::optional<B> destOps,
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::ConversionPatternRewriter &rewriter) {
[flang] Don't use Optional::hasValue (NFC) Flang C++ Style Guide tells us to avoid .has_value() in the predicate expressions of control flow statements. I am treating ternary expressions as control flow statements for the purpose of this patch. Differential Revision: https://reviews.llvm.org/D128622
2022-07-10 15:01:06 -07:00
if (destOps)
[flang] Use *X instead of X.getValue() (NFC) Per Flang C++ Style Guide, this patch replaces X.getValue() with *X where *X is protected by a presence test.
2022-07-16 00:24:02 -07:00
rewriter.replaceOpWithNewOp<mlir::LLVM::BrOp>(caseOp, *destOps, dest);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
else
[flang] Use std::nullopt instead of None (NFC) This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-03 12:14:21 -08:00
rewriter.replaceOpWithNewOp<mlir::LLVM::BrOp>(caseOp, std::nullopt, dest);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
static void genCaseLadderStep(mlir::Location loc, mlir::Value cmp,
mlir::Block *dest,
mlir/tblgen: use std::optional in generation This is part of an effort to migrate from llvm::Optional to std::optional. This patch changes the way mlir-tblgen generates .inc files, and modifies tests and documentation appropriately. It is a "no compromises" patch, and doesn't leave the user with an unpleasant mix of llvm::Optional and std::optional. A non-trivial change has been made to ControlFlowInterfaces to split one constructor into two, relating to a build failure on Windows. See also: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 Signed-off-by: Ramkumar Ramachandra <r@artagnon.com> Differential Revision: https://reviews.llvm.org/D138934
2022-12-14 11:39:19 +01:00
std::optional<mlir::ValueRange> destOps,
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::ConversionPatternRewriter &rewriter) {
auto *thisBlock = rewriter.getInsertionBlock();
auto *newBlock = createBlock(rewriter, dest);
rewriter.setInsertionPointToEnd(thisBlock);
genCondBrOp(loc, cmp, dest, destOps, rewriter, newBlock);
rewriter.setInsertionPointToEnd(newBlock);
}
/// Conversion of `fir.select_case`
///
/// The `fir.select_case` operation is converted to a if-then-else ladder.
/// Depending on the case condition type, one or several comparison and
/// conditional branching can be generated.
///
[flang] Fix duplicate word typos; NFC Those fixes were taken from https://reviews.llvm.org/D137338
2023-09-01 18:41:05 -07:00
/// A point value case such as `case(4)`, a lower bound case such as
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// `case(5:)` or an upper bound case such as `case(:3)` are converted to a
/// simple comparison between the selector value and the constant value in the
/// case. The block associated with the case condition is then executed if
/// the comparison succeed otherwise it branch to the next block with the
[flang] Fix duplicate word typos; NFC Those fixes were taken from https://reviews.llvm.org/D137338
2023-09-01 18:41:05 -07:00
/// comparison for the next case conditon.
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
///
/// A closed interval case condition such as `case(7:10)` is converted with a
/// first comparison and conditional branching for the lower bound. If
/// successful, it branch to a second block with the comparison for the
/// upper bound in the same case condition.
///
/// TODO: lowering of CHARACTER type cases is not handled yet.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct SelectCaseOpConversion : public fir::FIROpConversion<fir::SelectCaseOp> {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
using FIROpConversion::FIROpConversion;
[fir] Add conversion patterns for slice, shape, shapeshift and shift ops The information in these perations is used by other operation. At this point they should not have anymore uses. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113971 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-17 10:34:38 +01:00
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::SelectCaseOp caseOp, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
unsigned conds = caseOp.getNumConditions();
llvm::ArrayRef<mlir::Attribute> cases = caseOp.getCases().getValue();
// Type can be CHARACTER, INTEGER, or LOGICAL (C1145)
auto ty = caseOp.getSelector().getType();
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (mlir::isa<fir::CharacterType>(ty)) {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
TODO(caseOp.getLoc(), "fir.select_case codegen with character type");
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::failure();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
mlir::Value selector = caseOp.getSelector(adaptor.getOperands());
auto loc = caseOp.getLoc();
for (unsigned t = 0; t != conds; ++t) {
mlir::Block *dest = caseOp.getSuccessor(t);
mlir/tblgen: use std::optional in generation This is part of an effort to migrate from llvm::Optional to std::optional. This patch changes the way mlir-tblgen generates .inc files, and modifies tests and documentation appropriately. It is a "no compromises" patch, and doesn't leave the user with an unpleasant mix of llvm::Optional and std::optional. A non-trivial change has been made to ControlFlowInterfaces to split one constructor into two, relating to a build failure on Windows. See also: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 Signed-off-by: Ramkumar Ramachandra <r@artagnon.com> Differential Revision: https://reviews.llvm.org/D138934
2022-12-14 11:39:19 +01:00
std::optional<mlir::ValueRange> destOps =
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
caseOp.getSuccessorOperands(adaptor.getOperands(), t);
mlir/tblgen: use std::optional in generation This is part of an effort to migrate from llvm::Optional to std::optional. This patch changes the way mlir-tblgen generates .inc files, and modifies tests and documentation appropriately. It is a "no compromises" patch, and doesn't leave the user with an unpleasant mix of llvm::Optional and std::optional. A non-trivial change has been made to ControlFlowInterfaces to split one constructor into two, relating to a build failure on Windows. See also: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 Signed-off-by: Ramkumar Ramachandra <r@artagnon.com> Differential Revision: https://reviews.llvm.org/D138934
2022-12-14 11:39:19 +01:00
std::optional<mlir::ValueRange> cmpOps =
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
*caseOp.getCompareOperands(adaptor.getOperands(), t);
mlir::Attribute attr = cases[t];
[flang][CodeGen] Avoid out-of-bounds memory access in SelectCaseOp (#92955) `SelectCaseOp::getCompareOperands` may return an empty range for the "default" case. Do not dereference the range until it is expected to be non-empty. This was detected by address-sanitizer.
2024-05-22 10:52:17 -05:00
assert(mlir::isa<mlir::UnitAttr>(attr) || cmpOps.has_value());
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (mlir::isa<fir::PointIntervalAttr>(attr)) {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
auto cmp = rewriter.create<mlir::LLVM::ICmpOp>(
[flang][CodeGen] Avoid out-of-bounds memory access in SelectCaseOp (#92955) `SelectCaseOp::getCompareOperands` may return an empty range for the "default" case. Do not dereference the range until it is expected to be non-empty. This was detected by address-sanitizer.
2024-05-22 10:52:17 -05:00
loc, mlir::LLVM::ICmpPredicate::eq, selector, cmpOps->front());
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
genCaseLadderStep(loc, cmp, dest, destOps, rewriter);
continue;
}
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (mlir::isa<fir::LowerBoundAttr>(attr)) {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
auto cmp = rewriter.create<mlir::LLVM::ICmpOp>(
[flang][CodeGen] Avoid out-of-bounds memory access in SelectCaseOp (#92955) `SelectCaseOp::getCompareOperands` may return an empty range for the "default" case. Do not dereference the range until it is expected to be non-empty. This was detected by address-sanitizer.
2024-05-22 10:52:17 -05:00
loc, mlir::LLVM::ICmpPredicate::sle, cmpOps->front(), selector);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
genCaseLadderStep(loc, cmp, dest, destOps, rewriter);
continue;
}
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (mlir::isa<fir::UpperBoundAttr>(attr)) {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
auto cmp = rewriter.create<mlir::LLVM::ICmpOp>(
[flang][CodeGen] Avoid out-of-bounds memory access in SelectCaseOp (#92955) `SelectCaseOp::getCompareOperands` may return an empty range for the "default" case. Do not dereference the range until it is expected to be non-empty. This was detected by address-sanitizer.
2024-05-22 10:52:17 -05:00
loc, mlir::LLVM::ICmpPredicate::sle, selector, cmpOps->front());
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
genCaseLadderStep(loc, cmp, dest, destOps, rewriter);
continue;
}
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (mlir::isa<fir::ClosedIntervalAttr>(attr)) {
[flang][CodeGen] Avoid out-of-bounds memory access in SelectCaseOp (#92955) `SelectCaseOp::getCompareOperands` may return an empty range for the "default" case. Do not dereference the range until it is expected to be non-empty. This was detected by address-sanitizer.
2024-05-22 10:52:17 -05:00
mlir::Value caseArg0 = *cmpOps->begin();
auto cmp0 = rewriter.create<mlir::LLVM::ICmpOp>(
loc, mlir::LLVM::ICmpPredicate::sle, caseArg0, selector);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
auto *thisBlock = rewriter.getInsertionBlock();
auto *newBlock1 = createBlock(rewriter, dest);
auto *newBlock2 = createBlock(rewriter, dest);
rewriter.setInsertionPointToEnd(thisBlock);
[flang][CodeGen] Avoid out-of-bounds memory access in SelectCaseOp (#92955) `SelectCaseOp::getCompareOperands` may return an empty range for the "default" case. Do not dereference the range until it is expected to be non-empty. This was detected by address-sanitizer.
2024-05-22 10:52:17 -05:00
rewriter.create<mlir::LLVM::CondBrOp>(loc, cmp0, newBlock1, newBlock2);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
rewriter.setInsertionPointToEnd(newBlock1);
[flang][CodeGen] Avoid out-of-bounds memory access in SelectCaseOp (#92955) `SelectCaseOp::getCompareOperands` may return an empty range for the "default" case. Do not dereference the range until it is expected to be non-empty. This was detected by address-sanitizer.
2024-05-22 10:52:17 -05:00
mlir::Value caseArg1 = *(cmpOps->begin() + 1);
auto cmp1 = rewriter.create<mlir::LLVM::ICmpOp>(
loc, mlir::LLVM::ICmpPredicate::sle, selector, caseArg1);
genCondBrOp(loc, cmp1, dest, destOps, rewriter, newBlock2);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
rewriter.setInsertionPointToEnd(newBlock2);
continue;
}
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
assert(mlir::isa<mlir::UnitAttr>(attr));
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
assert((t + 1 == conds) && "unit must be last");
genBrOp(caseOp, dest, destOps, rewriter);
}
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[fir] Add conversion patterns for slice, shape, shapeshift and shift ops The information in these perations is used by other operation. At this point they should not have anymore uses. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113971 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-17 10:34:38 +01:00
}
};
[mlir][CF] Split `cf-to-llvm` from `func-to-llvm` (#120580) Do not run `cf-to-llvm` as part of `func-to-llvm`. This commit fixes https://github.com/llvm/llvm-project/issues/70982. This commit changes the way how `func.func` ops are lowered to LLVM. Previously, the signature of the entire region (i.e., entry block and all other blocks in the `func.func` op) was converted as part of the `func.func` lowering pattern. Now, only the entry block is converted. The remaining block signatures are converted together with `cf.br` and `cf.cond_br` as part of `cf-to-llvm`. All unstructured control flow is not converted as part of a single pass (`cf-to-llvm`). `func-to-llvm` no longer deals with unstructured control flow. Also add more test cases for control flow dialect ops. Note: This PR is in preparation of #120431, which adds an additional GPU-specific lowering for `cf.assert`. This was a problem because `cf.assert` used to be converted as part of `func-to-llvm`. Note for LLVM integration: If you see failures, add `-convert-cf-to-llvm` to your pass pipeline.
2024-12-20 13:46:45 +01:00
/// Helper function for converting select ops. This function converts the
/// signature of the given block. If the new block signature is different from
/// `expectedTypes`, returns "failure".
static llvm::FailureOr<mlir::Block *>
getConvertedBlock(mlir::ConversionPatternRewriter &rewriter,
const mlir::TypeConverter *converter,
mlir::Operation *branchOp, mlir::Block *block,
mlir::TypeRange expectedTypes) {
assert(converter && "expected non-null type converter");
assert(!block->isEntryBlock() && "entry blocks have no predecessors");
// There is nothing to do if the types already match.
if (block->getArgumentTypes() == expectedTypes)
return block;
// Compute the new block argument types and convert the block.
std::optional<mlir::TypeConverter::SignatureConversion> conversion =
converter->convertBlockSignature(block);
if (!conversion)
return rewriter.notifyMatchFailure(branchOp,
"could not compute block signature");
if (expectedTypes != conversion->getConvertedTypes())
return rewriter.notifyMatchFailure(
branchOp,
"mismatch between adaptor operand types and computed block signature");
return rewriter.applySignatureConversion(block, *conversion, converter);
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
template <typename OP>
[mlir][CF] Split `cf-to-llvm` from `func-to-llvm` (#120580) Do not run `cf-to-llvm` as part of `func-to-llvm`. This commit fixes https://github.com/llvm/llvm-project/issues/70982. This commit changes the way how `func.func` ops are lowered to LLVM. Previously, the signature of the entire region (i.e., entry block and all other blocks in the `func.func` op) was converted as part of the `func.func` lowering pattern. Now, only the entry block is converted. The remaining block signatures are converted together with `cf.br` and `cf.cond_br` as part of `cf-to-llvm`. All unstructured control flow is not converted as part of a single pass (`cf-to-llvm`). `func-to-llvm` no longer deals with unstructured control flow. Also add more test cases for control flow dialect ops. Note: This PR is in preparation of #120431, which adds an additional GPU-specific lowering for `cf.assert`. This was a problem because `cf.assert` used to be converted as part of `func-to-llvm`. Note for LLVM integration: If you see failures, add `-convert-cf-to-llvm` to your pass pipeline.
2024-12-20 13:46:45 +01:00
static llvm::LogicalResult
selectMatchAndRewrite(const fir::LLVMTypeConverter &lowering, OP select,
typename OP::Adaptor adaptor,
mlir::ConversionPatternRewriter &rewriter,
const mlir::TypeConverter *converter) {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
unsigned conds = select.getNumConditions();
auto cases = select.getCases().getValue();
mlir::Value selector = adaptor.getSelector();
auto loc = select.getLoc();
assert(conds > 0 && "select must have cases");
[fir] Add conversion patterns for slice, shape, shapeshift and shift ops The information in these perations is used by other operation. At this point they should not have anymore uses. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113971 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-17 10:34:38 +01:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
llvm::SmallVector<mlir::Block *> destinations;
llvm::SmallVector<mlir::ValueRange> destinationsOperands;
mlir::Block *defaultDestination;
mlir::ValueRange defaultOperands;
llvm::SmallVector<int32_t> caseValues;
[fir] Add conversion patterns for slice, shape, shapeshift and shift ops The information in these perations is used by other operation. At this point they should not have anymore uses. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113971 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-17 10:34:38 +01:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
for (unsigned t = 0; t != conds; ++t) {
mlir::Block *dest = select.getSuccessor(t);
auto destOps = select.getSuccessorOperands(adaptor.getOperands(), t);
const mlir::Attribute &attr = cases[t];
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (auto intAttr = mlir::dyn_cast<mlir::IntegerAttr>(attr)) {
[flang] Don't use Optional::hasValue (NFC) Flang C++ Style Guide tells us to avoid .has_value() in the predicate expressions of control flow statements. I am treating ternary expressions as control flow statements for the purpose of this patch. Differential Revision: https://reviews.llvm.org/D128622
2022-07-10 15:01:06 -07:00
destinationsOperands.push_back(destOps ? *destOps : mlir::ValueRange{});
[mlir][CF] Split `cf-to-llvm` from `func-to-llvm` (#120580) Do not run `cf-to-llvm` as part of `func-to-llvm`. This commit fixes https://github.com/llvm/llvm-project/issues/70982. This commit changes the way how `func.func` ops are lowered to LLVM. Previously, the signature of the entire region (i.e., entry block and all other blocks in the `func.func` op) was converted as part of the `func.func` lowering pattern. Now, only the entry block is converted. The remaining block signatures are converted together with `cf.br` and `cf.cond_br` as part of `cf-to-llvm`. All unstructured control flow is not converted as part of a single pass (`cf-to-llvm`). `func-to-llvm` no longer deals with unstructured control flow. Also add more test cases for control flow dialect ops. Note: This PR is in preparation of #120431, which adds an additional GPU-specific lowering for `cf.assert`. This was a problem because `cf.assert` used to be converted as part of `func-to-llvm`. Note for LLVM integration: If you see failures, add `-convert-cf-to-llvm` to your pass pipeline.
2024-12-20 13:46:45 +01:00
auto convertedBlock =
getConvertedBlock(rewriter, converter, select, dest,
mlir::TypeRange(destinationsOperands.back()));
if (mlir::failed(convertedBlock))
return mlir::failure();
destinations.push_back(*convertedBlock);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
caseValues.push_back(intAttr.getInt());
continue;
}
[flang] Use `isa/dyn_cast/cast/...` free functions. (#90432) The corresponding member functions are deprecated.
2024-04-29 09:16:22 +02:00
assert(mlir::dyn_cast_or_null<mlir::UnitAttr>(attr));
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
assert((t + 1 == conds) && "unit must be last");
[flang] Don't use Optional::hasValue (NFC) Flang C++ Style Guide tells us to avoid .has_value() in the predicate expressions of control flow statements. I am treating ternary expressions as control flow statements for the purpose of this patch. Differential Revision: https://reviews.llvm.org/D128622
2022-07-10 15:01:06 -07:00
defaultOperands = destOps ? *destOps : mlir::ValueRange{};
[mlir][CF] Split `cf-to-llvm` from `func-to-llvm` (#120580) Do not run `cf-to-llvm` as part of `func-to-llvm`. This commit fixes https://github.com/llvm/llvm-project/issues/70982. This commit changes the way how `func.func` ops are lowered to LLVM. Previously, the signature of the entire region (i.e., entry block and all other blocks in the `func.func` op) was converted as part of the `func.func` lowering pattern. Now, only the entry block is converted. The remaining block signatures are converted together with `cf.br` and `cf.cond_br` as part of `cf-to-llvm`. All unstructured control flow is not converted as part of a single pass (`cf-to-llvm`). `func-to-llvm` no longer deals with unstructured control flow. Also add more test cases for control flow dialect ops. Note: This PR is in preparation of #120431, which adds an additional GPU-specific lowering for `cf.assert`. This was a problem because `cf.assert` used to be converted as part of `func-to-llvm`. Note for LLVM integration: If you see failures, add `-convert-cf-to-llvm` to your pass pipeline.
2024-12-20 13:46:45 +01:00
auto convertedBlock = getConvertedBlock(rewriter, converter, select, dest,
mlir::TypeRange(defaultOperands));
if (mlir::failed(convertedBlock))
return mlir::failure();
defaultDestination = *convertedBlock;
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
[fir] Add conversion patterns for slice, shape, shapeshift and shift ops The information in these perations is used by other operation. At this point they should not have anymore uses. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113971 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-17 10:34:38 +01:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// LLVM::SwitchOp takes a i32 type for the selector.
if (select.getSelector().getType() != rewriter.getI32Type())
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
selector = rewriter.create<mlir::LLVM::TruncOp>(loc, rewriter.getI32Type(),
selector);
[fir] Add conversion patterns for slice, shape, shapeshift and shift ops The information in these perations is used by other operation. At this point they should not have anymore uses. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113971 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-17 10:34:38 +01:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
rewriter.replaceOpWithNewOp<mlir::LLVM::SwitchOp>(
select, selector,
/*defaultDestination=*/defaultDestination,
/*defaultOperands=*/defaultOperands,
/*caseValues=*/caseValues,
/*caseDestinations=*/destinations,
/*caseOperands=*/destinationsOperands,
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
/*branchWeights=*/llvm::ArrayRef<std::int32_t>());
[mlir][CF] Split `cf-to-llvm` from `func-to-llvm` (#120580) Do not run `cf-to-llvm` as part of `func-to-llvm`. This commit fixes https://github.com/llvm/llvm-project/issues/70982. This commit changes the way how `func.func` ops are lowered to LLVM. Previously, the signature of the entire region (i.e., entry block and all other blocks in the `func.func` op) was converted as part of the `func.func` lowering pattern. Now, only the entry block is converted. The remaining block signatures are converted together with `cf.br` and `cf.cond_br` as part of `cf-to-llvm`. All unstructured control flow is not converted as part of a single pass (`cf-to-llvm`). `func-to-llvm` no longer deals with unstructured control flow. Also add more test cases for control flow dialect ops. Note: This PR is in preparation of #120431, which adds an additional GPU-specific lowering for `cf.assert`. This was a problem because `cf.assert` used to be converted as part of `func-to-llvm`. Note for LLVM integration: If you see failures, add `-convert-cf-to-llvm` to your pass pipeline.
2024-12-20 13:46:45 +01:00
return mlir::success();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
/// conversion of fir::SelectOp to an if-then-else ladder
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct SelectOpConversion : public fir::FIROpConversion<fir::SelectOp> {
[flang][CodeGen] Transform `IsPresentOpConversion` and `AbsentOpConversion` This patch extends the `FIRToLLVMLowering` pass in Flang by adding hooks to transform `fir.is_present` and `fir.absent` to the LLVM dialect of MLIR. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Differential Revision: https://reviews.llvm.org/D113395 Originally written by: Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-08 11:35:48 +00:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::SelectOp op, OpAdaptor adaptor,
[flang][CodeGen] Transform `IsPresentOpConversion` and `AbsentOpConversion` This patch extends the `FIRToLLVMLowering` pass in Flang by adding hooks to transform `fir.is_present` and `fir.absent` to the LLVM dialect of MLIR. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Differential Revision: https://reviews.llvm.org/D113395 Originally written by: Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-08 11:35:48 +00:00
mlir::ConversionPatternRewriter &rewriter) const override {
[mlir][CF] Split `cf-to-llvm` from `func-to-llvm` (#120580) Do not run `cf-to-llvm` as part of `func-to-llvm`. This commit fixes https://github.com/llvm/llvm-project/issues/70982. This commit changes the way how `func.func` ops are lowered to LLVM. Previously, the signature of the entire region (i.e., entry block and all other blocks in the `func.func` op) was converted as part of the `func.func` lowering pattern. Now, only the entry block is converted. The remaining block signatures are converted together with `cf.br` and `cf.cond_br` as part of `cf-to-llvm`. All unstructured control flow is not converted as part of a single pass (`cf-to-llvm`). `func-to-llvm` no longer deals with unstructured control flow. Also add more test cases for control flow dialect ops. Note: This PR is in preparation of #120431, which adds an additional GPU-specific lowering for `cf.assert`. This was a problem because `cf.assert` used to be converted as part of `func-to-llvm`. Note for LLVM integration: If you see failures, add `-convert-cf-to-llvm` to your pass pipeline.
2024-12-20 13:46:45 +01:00
return selectMatchAndRewrite<fir::SelectOp>(lowerTy(), op, adaptor,
rewriter, getTypeConverter());
[flang][CodeGen] Transform `IsPresentOpConversion` and `AbsentOpConversion` This patch extends the `FIRToLLVMLowering` pass in Flang by adding hooks to transform `fir.is_present` and `fir.absent` to the LLVM dialect of MLIR. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Differential Revision: https://reviews.llvm.org/D113395 Originally written by: Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-08 11:35:48 +00:00
}
};
[flang][CodeGen] Transform `fir.emboxchar` to a sequence of LLVM MLIR This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.emboxchar` to a sequence of LLVM MLIR instructions. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Differential Revision: https://reviews.llvm.org/D113666 Patch originally written by: Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-11 13:14:01 +00:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// conversion of fir::SelectRankOp to an if-then-else ladder
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct SelectRankOpConversion : public fir::FIROpConversion<fir::SelectRankOp> {
[flang][CodeGen] Transform `fir.emboxchar` to a sequence of LLVM MLIR This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.emboxchar` to a sequence of LLVM MLIR instructions. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Differential Revision: https://reviews.llvm.org/D113666 Patch originally written by: Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-11 13:14:01 +00:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::SelectRankOp op, OpAdaptor adaptor,
[flang][CodeGen] Transform `fir.emboxchar` to a sequence of LLVM MLIR This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.emboxchar` to a sequence of LLVM MLIR instructions. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Differential Revision: https://reviews.llvm.org/D113666 Patch originally written by: Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-11 13:14:01 +00:00
mlir::ConversionPatternRewriter &rewriter) const override {
[mlir][CF] Split `cf-to-llvm` from `func-to-llvm` (#120580) Do not run `cf-to-llvm` as part of `func-to-llvm`. This commit fixes https://github.com/llvm/llvm-project/issues/70982. This commit changes the way how `func.func` ops are lowered to LLVM. Previously, the signature of the entire region (i.e., entry block and all other blocks in the `func.func` op) was converted as part of the `func.func` lowering pattern. Now, only the entry block is converted. The remaining block signatures are converted together with `cf.br` and `cf.cond_br` as part of `cf-to-llvm`. All unstructured control flow is not converted as part of a single pass (`cf-to-llvm`). `func-to-llvm` no longer deals with unstructured control flow. Also add more test cases for control flow dialect ops. Note: This PR is in preparation of #120431, which adds an additional GPU-specific lowering for `cf.assert`. This was a problem because `cf.assert` used to be converted as part of `func-to-llvm`. Note for LLVM integration: If you see failures, add `-convert-cf-to-llvm` to your pass pipeline.
2024-12-20 13:46:45 +01:00
return selectMatchAndRewrite<fir::SelectRankOp>(
lowerTy(), op, adaptor, rewriter, getTypeConverter());
[flang][CodeGen] Transform `fir.emboxchar` to a sequence of LLVM MLIR This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.emboxchar` to a sequence of LLVM MLIR instructions. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Differential Revision: https://reviews.llvm.org/D113666 Patch originally written by: Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-11 13:14:01 +00:00
}
};
[flang][CodeGen] Transform `fir.unboxchar` to a sequence of LLVM MLIR This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.unboxchar` to a sequence of LLVM MLIR instructions. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Differential Revision: https://reviews.llvm.org/D113747 Originally written by: Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-10 13:24:56 +00:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// Lower `fir.select_type` to LLVM IR dialect.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct SelectTypeOpConversion : public fir::FIROpConversion<fir::SelectTypeOp> {
[flang][CodeGen] Transform `fir.boxchar_len` to a sequence of LLVM MLIR This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.boxchar_len` to a sequence of LLVM MLIR instructions. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Differential Revision: https://reviews.llvm.org/D113763 Originally written by: Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-12 13:25:42 +00:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::SelectTypeOp select, OpAdaptor adaptor,
[flang][CodeGen] Transform `fir.boxchar_len` to a sequence of LLVM MLIR This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.boxchar_len` to a sequence of LLVM MLIR instructions. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Differential Revision: https://reviews.llvm.org/D113763 Originally written by: Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-12 13:25:42 +00:00
mlir::ConversionPatternRewriter &rewriter) const override {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::emitError(select.getLoc(),
"fir.select_type should have already been converted");
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::failure();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
};
[flang][CodeGen] Transform `fir.boxchar_len` to a sequence of LLVM MLIR This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.boxchar_len` to a sequence of LLVM MLIR instructions. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Differential Revision: https://reviews.llvm.org/D113763 Originally written by: Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-12 13:25:42 +00:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// `fir.store` --> `llvm.store`
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct StoreOpConversion : public fir::FIROpConversion<fir::StoreOp> {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
using FIROpConversion::FIROpConversion;
[flang][CodeGen] Transform `fir.boxchar_len` to a sequence of LLVM MLIR This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.boxchar_len` to a sequence of LLVM MLIR instructions. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Differential Revision: https://reviews.llvm.org/D113763 Originally written by: Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-12 13:25:42 +00:00
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::StoreOp store, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
[flang] Generate TBAA information. This is initial version of TBAA information generation for Flang generated IR. The desired behavior is that TBAA type descriptors are generated for FIR types during FIR to LLVM types conversion, and then TBAA access tags are attached to memory accessing operations when they are converted to LLVM IR dialect. In the initial version the type conversion is not producing TBAA type descriptors, and all memory accesses are just partitioned into two sets of box and non-box accesses, which can never alias. The TBAA generation is enabled by default at >O0 optimization levels. TBAA generation may also be enabled via `apply-tbaa` option of `fir-to-llvm-ir` conversion pass. `-mllvm -disable-tbaa` engineering option allows disabling TBAA generation to override Flang's default (e.g. when -O1 is used). SPEC CPU2006/437.leslie3d speeds up by more than 2x on Icelake. Reviewed By: jeanPerier, clementval Differential Revision: https://reviews.llvm.org/D141820
2023-01-17 09:08:43 -08:00
mlir::Location loc = store.getLoc();
mlir::Type storeTy = store.getValue().getType();
[flang] allow assumed-rank box in fir.store (#95980) Codegen is done with a memcpy using the rank from the "value" descriptor like for the fir.load case. Rational described in https://github.com/llvm/llvm-project/blob/main/flang/docs/AssumedRank.md.
2024-06-19 10:12:19 +02:00
mlir::Value llvmValue = adaptor.getValue();
mlir::Value llvmMemref = adaptor.getMemref();
mlir::LLVM::AliasAnalysisOpInterface newOp;
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (auto boxTy = mlir::dyn_cast<fir::BaseBoxType>(storeTy)) {
[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692) !llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang codegen still generated them and relied on mlir.llvm codegen to LLVM to turn them into opaque pointers. This patch update FIR codegen to directly emit and work with LLVM opaque pointers. Addresses https://github.com/llvm/llvm-project/issues/69303 - All places generating GEPs need to add an extra type argument with the base type (the T that was previously in the llvm.ptr<T> of the base). - llvm.alloca must also be provided the object type. In the process, I doscovered that we were shamelessly copying all the attribute from fir.alloca to the llvm.alloca, which makes no sense for the operand segments. The updated code that cannot take an attribute dictionnary in the llvm.alloca builder with opaque pointers only propagate the "pinned" and "bindc_name" attributes to help debugging the generated IR. - Updating all the places that rely on getting the llvm object type from lowered llvm.ptr<T> arguments to get it from a type conversion of the original fir types. - Updating all the places that were generating llvm.ptr<T> types to generate the opaque llvm.ptr type. - Updating all the codegen tests checking generated MLIR llvm dialect. Many tests are testing directly LLVM IR, and this change is a no-op for those (which is expected).
2023-10-25 09:42:28 +02:00
mlir::Type llvmBoxTy = lowerTy().convertBoxTypeAsStruct(boxTy);
[flang][fir] always use memcpy for fir.box (#113949) @jeanPerier explained the importance of converting box loads and stores into `memcpy`s instead of aggregate loads and stores, and I'll do my best to explain it here. * [(godbolt link) Example comparing opt transformations on memcpys vs aggregate load/stores](https://godbolt.org/z/be7xM83cG) * LLVM can more effectively reason about memcpys compared to aggregate load/stores. * This came up when others were discussing array descriptors for assumed-rank arrays passed to `bind(c)` subroutines, with the implication that the array descriptors are known to have lower bounds of 1 and that they are not pointer/allocatable types. * [(godbolt link) Clang also uses memcpys so we should probably follow them, assuming the clang developers are generatign what they know Opt will handle more effectively.](https://godbolt.org/z/YT4x7387W) * This currently may not help much without the `nocapture` attribute being propagated to function calls, but [it looks like someone may do this soon (discourse link)](https://discourse.llvm.org/t/applying-the-nocapture-attribute-to-reference-passed-arguments-in-fortran-subroutines/81401/23) or I can do this in a follow-up patch. Note on test `flang/test/Fir/embox-char.fir`: it looks like the original test was auto-generated. I wasn't too sure which parts were especially important to test, so I regenerated the test. If we want the updated version to look more like the old version, I'll make those changes.
2024-10-30 09:50:27 -07:00
// Always use memcpy because LLVM is not as effective at optimizing
// aggregate loads/stores as it is optimizing memcpy.
TypePair boxTypePair{boxTy, llvmBoxTy};
mlir::Value boxSize =
computeBoxSize(loc, boxTypePair, llvmValue, rewriter);
newOp = rewriter.create<mlir::LLVM::MemcpyOp>(
loc, llvmMemref, llvmValue, boxSize, /*isVolatile=*/false);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
} else {
[flang] allow assumed-rank box in fir.store (#95980) Codegen is done with a memcpy using the rank from the "value" descriptor like for the fir.load case. Rational described in https://github.com/llvm/llvm-project/blob/main/flang/docs/AssumedRank.md.
2024-06-19 10:12:19 +02:00
newOp = rewriter.create<mlir::LLVM::StoreOp>(loc, llvmValue, llvmMemref);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
[flang][FIR] add FirAliasAnalysisOpInterface (#68317) This interface allows (HL)FIR passes to add TBAA information to fir.load and fir.store. If present, these TBAA tags take precedence over those added during CodeGen. We can't reuse mlir::LLVMIR::AliasAnalysisOpInterface because that uses the mlir::LLVMIR namespace so it tries to define methods for fir operations in the wrong namespace. But I did re-use the tbaa tag type to minimise boilerplate code. The new builders are to preserve the old interface without the tbaa tag.
2023-10-11 15:06:50 +01:00
if (std::optional<mlir::ArrayAttr> optionalTag = store.getTbaa())
[flang] allow assumed-rank box in fir.store (#95980) Codegen is done with a memcpy using the rank from the "value" descriptor like for the fir.load case. Rational described in https://github.com/llvm/llvm-project/blob/main/flang/docs/AssumedRank.md.
2024-06-19 10:12:19 +02:00
newOp.setTBAATags(*optionalTag);
[flang][FIR] add FirAliasAnalysisOpInterface (#68317) This interface allows (HL)FIR passes to add TBAA information to fir.load and fir.store. If present, these TBAA tags take precedence over those added during CodeGen. We can't reuse mlir::LLVMIR::AliasAnalysisOpInterface because that uses the mlir::LLVMIR namespace so it tries to define methods for fir operations in the wrong namespace. But I did re-use the tbaa tag type to minimise boilerplate code. The new builders are to preserve the old interface without the tbaa tag.
2023-10-11 15:06:50 +01:00
else
[flang] allow assumed-rank box in fir.store (#95980) Codegen is done with a memcpy using the rank from the "value" descriptor like for the fir.load case. Rational described in https://github.com/llvm/llvm-project/blob/main/flang/docs/AssumedRank.md.
2024-06-19 10:12:19 +02:00
attachTBAATag(newOp, storeTy, storeTy, nullptr);
[flang] Generate TBAA information. This is initial version of TBAA information generation for Flang generated IR. The desired behavior is that TBAA type descriptors are generated for FIR types during FIR to LLVM types conversion, and then TBAA access tags are attached to memory accessing operations when they are converted to LLVM IR dialect. In the initial version the type conversion is not producing TBAA type descriptors, and all memory accesses are just partitioned into two sets of box and non-box accesses, which can never alias. The TBAA generation is enabled by default at >O0 optimization levels. TBAA generation may also be enabled via `apply-tbaa` option of `fir-to-llvm-ir` conversion pass. `-mllvm -disable-tbaa` engineering option allows disabling TBAA generation to override Flang's default (e.g. when -O1 is used). SPEC CPU2006/437.leslie3d speeds up by more than 2x on Icelake. Reviewed By: jeanPerier, clementval Differential Revision: https://reviews.llvm.org/D141820
2023-01-17 09:08:43 -08:00
rewriter.eraseOp(store);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[flang][CodeGen] Transform `fir.boxchar_len` to a sequence of LLVM MLIR This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.boxchar_len` to a sequence of LLVM MLIR instructions. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Differential Revision: https://reviews.llvm.org/D113763 Originally written by: Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-12 13:25:42 +00:00
}
};
[flang] introduce fir.copy to avoid load store of aggregates (#130289) Introduce a FIR operation to do memcopy/memmove of compile time constant size types. This is to avoid requiring derived type copies to done with load/store which is badly supported in LLVM when the aggregate type is "big" (no threshold can easily be defined here, better to always avoid them for fir.type). This was the root cause of the regressions caused by #114002 which introduced a load/store of fir.type<> which caused hand/asserts to fire in LLVM on several benchmarks. See https://llvm.org/docs/Frontend/PerformanceTips.html#avoid-creating-values-of-aggregate-type
2025-03-11 09:31:03 +01:00
/// `fir.copy` --> `llvm.memcpy` or `llvm.memmove`
struct CopyOpConversion : public fir::FIROpConversion<fir::CopyOp> {
using FIROpConversion::FIROpConversion;
llvm::LogicalResult
matchAndRewrite(fir::CopyOp copy, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
mlir::Location loc = copy.getLoc();
mlir::Value llvmSource = adaptor.getSource();
mlir::Value llvmDestination = adaptor.getDestination();
mlir::Type i64Ty = mlir::IntegerType::get(rewriter.getContext(), 64);
mlir::Type copyTy = fir::unwrapRefType(copy.getSource().getType());
mlir::Value copySize =
genTypeStrideInBytes(loc, i64Ty, rewriter, convertType(copyTy));
mlir::LLVM::AliasAnalysisOpInterface newOp;
if (copy.getNoOverlap())
newOp = rewriter.create<mlir::LLVM::MemcpyOp>(
loc, llvmDestination, llvmSource, copySize, /*isVolatile=*/false);
else
newOp = rewriter.create<mlir::LLVM::MemmoveOp>(
loc, llvmDestination, llvmSource, copySize, /*isVolatile=*/false);
// TODO: propagate TBAA once FirAliasTagOpInterface added to CopyOp.
attachTBAATag(newOp, copyTy, copyTy, nullptr);
rewriter.eraseOp(copy);
return mlir::success();
}
};
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
namespace {
[flang][CodeGen] Transform `fir.unboxchar` to a sequence of LLVM MLIR This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.unboxchar` to a sequence of LLVM MLIR instructions. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Differential Revision: https://reviews.llvm.org/D113747 Originally written by: Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-10 13:24:56 +00:00
/// Convert `fir.unboxchar` into two `llvm.extractvalue` instructions. One for
/// the character buffer and one for the buffer length.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct UnboxCharOpConversion : public fir::FIROpConversion<fir::UnboxCharOp> {
[flang][CodeGen] Transform `fir.unboxchar` to a sequence of LLVM MLIR This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.unboxchar` to a sequence of LLVM MLIR instructions. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Differential Revision: https://reviews.llvm.org/D113747 Originally written by: Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-10 13:24:56 +00:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[flang][CodeGen] Transform `fir.unboxchar` to a sequence of LLVM MLIR This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.unboxchar` to a sequence of LLVM MLIR instructions. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Differential Revision: https://reviews.llvm.org/D113747 Originally written by: Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-10 13:24:56 +00:00
matchAndRewrite(fir::UnboxCharOp unboxchar, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
mlir::Type lenTy = convertType(unboxchar.getType(1));
mlir::Value tuple = adaptor.getOperands()[0];
mlir::Location loc = unboxchar.getLoc();
mlir::Value ptrToBuffer =
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
rewriter.create<mlir::LLVM::ExtractValueOp>(loc, tuple, 0);
[flang][CodeGen] Transform `fir.unboxchar` to a sequence of LLVM MLIR This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.unboxchar` to a sequence of LLVM MLIR instructions. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Differential Revision: https://reviews.llvm.org/D113747 Originally written by: Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-10 13:24:56 +00:00
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
auto len = rewriter.create<mlir::LLVM::ExtractValueOp>(loc, tuple, 1);
[flang][CodeGen] Transform `fir.unboxchar` to a sequence of LLVM MLIR This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.unboxchar` to a sequence of LLVM MLIR instructions. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Differential Revision: https://reviews.llvm.org/D113747 Originally written by: Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-10 13:24:56 +00:00
mlir::Value lenAfterCast = integerCast(loc, rewriter, lenTy, len);
rewriter.replaceOp(unboxchar,
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
llvm::ArrayRef<mlir::Value>{ptrToBuffer, lenAfterCast});
return mlir::success();
[flang][CodeGen] Transform `fir.unboxchar` to a sequence of LLVM MLIR This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.unboxchar` to a sequence of LLVM MLIR instructions. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Differential Revision: https://reviews.llvm.org/D113747 Originally written by: Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-10 13:24:56 +00:00
}
};
[Flang] Notify conversion failure for Proc ops, types Add the FIR to LLVM conversion patterns for the BoxProcHostOp, EmboxProcOp, and UnboxProcOp ops and the boxproc type. These are currently unimplemented. Implementation will come at a later time when support for Fortran 2003 procedure pointer feature is added. Reviewed By: clementval, rovka Differential Revision: https://reviews.llvm.org/D113879 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-18 11:26:53 +00:00
/// Lower `fir.unboxproc` operation. Unbox a procedure box value, yielding its
/// components.
/// TODO: Part of supporting Fortran 2003 procedure pointers.
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct UnboxProcOpConversion : public fir::FIROpConversion<fir::UnboxProcOp> {
[Flang] Notify conversion failure for Proc ops, types Add the FIR to LLVM conversion patterns for the BoxProcHostOp, EmboxProcOp, and UnboxProcOp ops and the boxproc type. These are currently unimplemented. Implementation will come at a later time when support for Fortran 2003 procedure pointer feature is added. Reviewed By: clementval, rovka Differential Revision: https://reviews.llvm.org/D113879 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-18 11:26:53 +00:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] Notify conversion failure for Proc ops, types Add the FIR to LLVM conversion patterns for the BoxProcHostOp, EmboxProcOp, and UnboxProcOp ops and the boxproc type. These are currently unimplemented. Implementation will come at a later time when support for Fortran 2003 procedure pointer feature is added. Reviewed By: clementval, rovka Differential Revision: https://reviews.llvm.org/D113879 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-18 11:26:53 +00:00
matchAndRewrite(fir::UnboxProcOp unboxproc, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
[Flang] Replace notifyMatchFailure with TODO hard failures For unimplemented patterns we revert to using TODO hard failures instead of notifyMatchFailure. For fir.select_type revert to using mlir::emiterror. For the fir.embox TODO on a type with len params we cannot add a test since the type cannot be converted to llvm. Adding negative tests using not and checking for the error message. TODO exits with an error in a build without assertion but aborts in a build with assertions. Abort requires using not with the --crash option. The two different usages of not is handled by using a custom command %not_todo_cmd which is converted to not or not --crash depending on the presence or absence of assertions. Using llvm-config to check the presence of assertions. Reviewed By: clementval, awarzynski Differential Revision: https://reviews.llvm.org/D114371
2021-12-01 22:12:12 +00:00
TODO(unboxproc.getLoc(), "fir.unboxproc codegen");
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::failure();
[Flang] Notify conversion failure for Proc ops, types Add the FIR to LLVM conversion patterns for the BoxProcHostOp, EmboxProcOp, and UnboxProcOp ops and the boxproc type. These are currently unimplemented. Implementation will come at a later time when support for Fortran 2003 procedure pointer feature is added. Reviewed By: clementval, rovka Differential Revision: https://reviews.llvm.org/D113879 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-18 11:26:53 +00:00
}
};
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// convert to LLVM IR dialect `undef`
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct UndefOpConversion : public fir::FIROpConversion<fir::UndefOp> {
[flang][CodeGen] Transform `fir.field_index` to a sequence of LLVM MLIR This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.field_index` to a sequence of LLVM MLIR instructions. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Differential Revision: https://reviews.llvm.org/D113988 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-16 08:36:05 +00:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::UndefOp undef, OpAdaptor,
[flang][CodeGen] Transform `fir.field_index` to a sequence of LLVM MLIR This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.field_index` to a sequence of LLVM MLIR instructions. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Differential Revision: https://reviews.llvm.org/D113988 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-16 08:36:05 +00:00
mlir::ConversionPatternRewriter &rewriter) const override {
[FIR] Avoid generating llvm.undef for dummy scoping info (#128098) Dummy scoping operations are generated to keep track of scopes for purpose of Fortran level analyses like Alias Analysis. For codegen, the scoping info is converted to a fir.undef during pre-codegen rewrite. Then during declare lowering, this info is no longer used - but it is still translated to llvm.undef. I cleaned up so it is simply erased. The generated LLVM should now no longer have a stray undef which looks off when trying to make sense of the IR. Co-authored-by: Razvan Lupusoru <rlupusoru@nvidia.com>
2025-02-20 18:49:23 -08:00
if (mlir::isa<fir::DummyScopeType>(undef.getType())) {
// Dummy scoping is used for Fortran analyses like AA. Once it gets to
// pre-codegen rewrite it is erased and a fir.undef is created to
// feed to the fir declare operation. Thus, during codegen, we can
// simply erase is as it is no longer used.
rewriter.eraseOp(undef);
return mlir::success();
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
rewriter.replaceOpWithNewOp<mlir::LLVM::UndefOp>(
undef, convertType(undef.getType()));
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[flang][CodeGen] Transform `fir.field_index` to a sequence of LLVM MLIR This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `fir.field_index` to a sequence of LLVM MLIR instructions. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Differential Revision: https://reviews.llvm.org/D113988 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com>
2021-11-16 08:36:05 +00:00
}
};
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct ZeroOpConversion : public fir::FIROpConversion<fir::ZeroOp> {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
using FIROpConversion::FIROpConversion;
[flang][codegen] Add a conversion for `!fir.coordinate_of` - part 1 This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `!fir.coordinate_of` into a sequence of LLVM MLIR instructions. The following cases are currently supported: 1. the input object is a `!fir.complex` (wrapped in e.g. `!fir.ref` or `!fir.box`) 2. the input object is wrapped in a `!fir.box` (including e.g. `!fir.array`). Note that `!fir.complex` inside a `!fir.box` falls under case 1. above (i.e. it's a special case regardless of the wrapping type). This is part of the upstreaming effort from the `!fir-dev` branch in [1]. Differential Revision: https://reviews.llvm.org/D114159 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
2021-11-17 10:03:19 +00:00
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::ZeroOp zero, OpAdaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
mlir::Type ty = convertType(zero.getType());
[flang] zero initialized all saved values without initial values (#67693) This is not standard but is vastly expected by existing code. This was implemented by https://reviews.llvm.org/D149877 for simple scalars, but MLIR lacked a generic way to deal with aggregate types (arrays and derived type). Support was recently added in https://github.com/llvm/llvm-project/pull/65508. Leverage it to zero initialize all types.
2023-09-29 08:51:30 +02:00
rewriter.replaceOpWithNewOp<mlir::LLVM::ZeroOp>(zero, ty);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[flang][codegen] Add a conversion for `!fir.coordinate_of` - part 1 This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `!fir.coordinate_of` into a sequence of LLVM MLIR instructions. The following cases are currently supported: 1. the input object is a `!fir.complex` (wrapped in e.g. `!fir.ref` or `!fir.box`) 2. the input object is wrapped in a `!fir.box` (including e.g. `!fir.array`). Note that `!fir.complex` inside a `!fir.box` falls under case 1. above (i.e. it's a special case regardless of the wrapping type). This is part of the upstreaming effort from the `!fir-dev` branch in [1]. Differential Revision: https://reviews.llvm.org/D114159 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
2021-11-17 10:03:19 +00:00
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
};
[flang][codegen] Add a conversion for `!fir.coordinate_of` - part 1 This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `!fir.coordinate_of` into a sequence of LLVM MLIR instructions. The following cases are currently supported: 1. the input object is a `!fir.complex` (wrapped in e.g. `!fir.ref` or `!fir.box`) 2. the input object is wrapped in a `!fir.box` (including e.g. `!fir.array`). Note that `!fir.complex` inside a `!fir.box` falls under case 1. above (i.e. it's a special case regardless of the wrapping type). This is part of the upstreaming effort from the `!fir-dev` branch in [1]. Differential Revision: https://reviews.llvm.org/D114159 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
2021-11-17 10:03:19 +00:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// `fir.unreachable` --> `llvm.unreachable`
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct UnreachableOpConversion
: public fir::FIROpConversion<fir::UnreachableOp> {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::UnreachableOp unreach, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
rewriter.replaceOpWithNewOp<mlir::LLVM::UnreachableOp>(unreach);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[flang][codegen] Add a conversion for `!fir.coordinate_of` - part 1 This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `!fir.coordinate_of` into a sequence of LLVM MLIR instructions. The following cases are currently supported: 1. the input object is a `!fir.complex` (wrapped in e.g. `!fir.ref` or `!fir.box`) 2. the input object is wrapped in a `!fir.box` (including e.g. `!fir.array`). Note that `!fir.complex` inside a `!fir.box` falls under case 1. above (i.e. it's a special case regardless of the wrapping type). This is part of the upstreaming effort from the `!fir-dev` branch in [1]. Differential Revision: https://reviews.llvm.org/D114159 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
2021-11-17 10:03:19 +00:00
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
};
[flang][codegen] Add a conversion for `!fir.coordinate_of` - part 1 This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `!fir.coordinate_of` into a sequence of LLVM MLIR instructions. The following cases are currently supported: 1. the input object is a `!fir.complex` (wrapped in e.g. `!fir.ref` or `!fir.box`) 2. the input object is wrapped in a `!fir.box` (including e.g. `!fir.array`). Note that `!fir.complex` inside a `!fir.box` falls under case 1. above (i.e. it's a special case regardless of the wrapping type). This is part of the upstreaming effort from the `!fir-dev` branch in [1]. Differential Revision: https://reviews.llvm.org/D114159 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
2021-11-17 10:03:19 +00:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// `fir.is_present` -->
/// ```
/// %0 = llvm.mlir.constant(0 : i64)
/// %1 = llvm.ptrtoint %0
/// %2 = llvm.icmp "ne" %1, %0 : i64
/// ```
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct IsPresentOpConversion : public fir::FIROpConversion<fir::IsPresentOp> {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
using FIROpConversion::FIROpConversion;
[flang][codegen] Add a conversion for `!fir.coordinate_of` - part 1 This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `!fir.coordinate_of` into a sequence of LLVM MLIR instructions. The following cases are currently supported: 1. the input object is a `!fir.complex` (wrapped in e.g. `!fir.ref` or `!fir.box`) 2. the input object is wrapped in a `!fir.box` (including e.g. `!fir.array`). Note that `!fir.complex` inside a `!fir.box` falls under case 1. above (i.e. it's a special case regardless of the wrapping type). This is part of the upstreaming effort from the `!fir-dev` branch in [1]. Differential Revision: https://reviews.llvm.org/D114159 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
2021-11-17 10:03:19 +00:00
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::IsPresentOp isPresent, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
mlir::Type idxTy = lowerTy().indexType();
mlir::Location loc = isPresent.getLoc();
auto ptr = adaptor.getOperands()[0];
[flang][codegen] Add a conversion for `!fir.coordinate_of` - part 1 This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `!fir.coordinate_of` into a sequence of LLVM MLIR instructions. The following cases are currently supported: 1. the input object is a `!fir.complex` (wrapped in e.g. `!fir.ref` or `!fir.box`) 2. the input object is wrapped in a `!fir.box` (including e.g. `!fir.array`). Note that `!fir.complex` inside a `!fir.box` falls under case 1. above (i.e. it's a special case regardless of the wrapping type). This is part of the upstreaming effort from the `!fir-dev` branch in [1]. Differential Revision: https://reviews.llvm.org/D114159 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
2021-11-17 10:03:19 +00:00
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
if (mlir::isa<fir::BoxCharType>(isPresent.getVal().getType())) {
[MLIR] Update pass declarations to new autogenerated files The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow dropping the old infrastructure. Reviewed By: mehdi_amini, rriddle Differential Review: https://reviews.llvm.org/D132838
2022-08-31 10:16:29 +02:00
[[maybe_unused]] auto structTy =
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406) …ted. (#89998)" (#90250) This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087. This change removes calls to the deprecated member functions. It does not mark the functions deprecated yet and does not disable the deprecation warning in TypeSwitch. This seems to cause problems with MSVC.
2024-04-28 22:01:42 +02:00
mlir::cast<mlir::LLVM::LLVMStructType>(ptr.getType());
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
assert(!structTy.isOpaque() && !structTy.getBody().empty());
[flang][codegen] Add a conversion for `fir.coordinate_of` - part 2 This patch extends the `FIRToLLVMLowering` pass in Flang by extending the hook to transform `fir.coordinate_of` into a sequence of LLVM MLIR instructions (i.e. `CoordinateOpConversion::doRewrite`). The following case is added: 3.1 the input object is inside `!fir.ref` (e.g. `!fir.ref<!fir.array>` or `!fir.ref<!fir.type>`). 3.2 the input object is inside `!fir.ptr` (e.g. `!fir.ptr<!fir.array>` or `!fir.ptr<!fir.type>`). From the point of view of the conversion, 3.1 and 3.2 are currently identical. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Originally written by: Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com> Depends on: D114159 Differential Revision: https://reviews.llvm.org/D115333
2021-11-23 18:13:51 +00:00
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
ptr = rewriter.create<mlir::LLVM::ExtractValueOp>(loc, ptr, 0);
[flang][codegen] Add a conversion for `fir.coordinate_of` - part 2 This patch extends the `FIRToLLVMLowering` pass in Flang by extending the hook to transform `fir.coordinate_of` into a sequence of LLVM MLIR instructions (i.e. `CoordinateOpConversion::doRewrite`). The following case is added: 3.1 the input object is inside `!fir.ref` (e.g. `!fir.ref<!fir.array>` or `!fir.ref<!fir.type>`). 3.2 the input object is inside `!fir.ptr` (e.g. `!fir.ptr<!fir.array>` or `!fir.ptr<!fir.type>`). From the point of view of the conversion, 3.1 and 3.2 are currently identical. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Originally written by: Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com> Depends on: D114159 Differential Revision: https://reviews.llvm.org/D115333
2021-11-23 18:13:51 +00:00
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::LLVM::ConstantOp c0 =
genConstantIndex(isPresent.getLoc(), idxTy, rewriter, 0);
auto addr = rewriter.create<mlir::LLVM::PtrToIntOp>(loc, idxTy, ptr);
rewriter.replaceOpWithNewOp<mlir::LLVM::ICmpOp>(
isPresent, mlir::LLVM::ICmpPredicate::ne, addr, c0);
[flang][codegen] Add a conversion for `fir.coordinate_of` - part 2 This patch extends the `FIRToLLVMLowering` pass in Flang by extending the hook to transform `fir.coordinate_of` into a sequence of LLVM MLIR instructions (i.e. `CoordinateOpConversion::doRewrite`). The following case is added: 3.1 the input object is inside `!fir.ref` (e.g. `!fir.ref<!fir.array>` or `!fir.ref<!fir.type>`). 3.2 the input object is inside `!fir.ptr` (e.g. `!fir.ptr<!fir.array>` or `!fir.ptr<!fir.type>`). From the point of view of the conversion, 3.1 and 3.2 are currently identical. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Originally written by: Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com> Depends on: D114159 Differential Revision: https://reviews.llvm.org/D115333
2021-11-23 18:13:51 +00:00
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[flang][codegen] Add a conversion for `fir.coordinate_of` - part 2 This patch extends the `FIRToLLVMLowering` pass in Flang by extending the hook to transform `fir.coordinate_of` into a sequence of LLVM MLIR instructions (i.e. `CoordinateOpConversion::doRewrite`). The following case is added: 3.1 the input object is inside `!fir.ref` (e.g. `!fir.ref<!fir.array>` or `!fir.ref<!fir.type>`). 3.2 the input object is inside `!fir.ptr` (e.g. `!fir.ptr<!fir.array>` or `!fir.ptr<!fir.type>`). From the point of view of the conversion, 3.1 and 3.2 are currently identical. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Originally written by: Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com> Depends on: D114159 Differential Revision: https://reviews.llvm.org/D115333
2021-11-23 18:13:51 +00:00
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
};
[flang][codegen] Add a conversion for `fir.coordinate_of` - part 2 This patch extends the `FIRToLLVMLowering` pass in Flang by extending the hook to transform `fir.coordinate_of` into a sequence of LLVM MLIR instructions (i.e. `CoordinateOpConversion::doRewrite`). The following case is added: 3.1 the input object is inside `!fir.ref` (e.g. `!fir.ref<!fir.array>` or `!fir.ref<!fir.type>`). 3.2 the input object is inside `!fir.ptr` (e.g. `!fir.ptr<!fir.array>` or `!fir.ptr<!fir.type>`). From the point of view of the conversion, 3.1 and 3.2 are currently identical. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Originally written by: Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com> Depends on: D114159 Differential Revision: https://reviews.llvm.org/D115333
2021-11-23 18:13:51 +00:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// Create value signaling an absent optional argument in a call, e.g.
[mlir][llvm] Replace NullOp by ZeroOp (#67183) This revision replaces the LLVM dialect NullOp by the recently introduced ZeroOp. The ZeroOp is more generic in the sense that it represents zero values of any LLVM type rather than null pointers only. This is a follow to https://github.com/llvm/llvm-project/pull/65508
2023-09-25 11:11:52 +02:00
/// `fir.absent !fir.ref<i64>` --> `llvm.mlir.zero : !llvm.ptr<i64>`
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct AbsentOpConversion : public fir::FIROpConversion<fir::AbsentOp> {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
using FIROpConversion::FIROpConversion;
[flang][codegen] Add a conversion for `!fir.coordinate_of` - part 1 This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `!fir.coordinate_of` into a sequence of LLVM MLIR instructions. The following cases are currently supported: 1. the input object is a `!fir.complex` (wrapped in e.g. `!fir.ref` or `!fir.box`) 2. the input object is wrapped in a `!fir.box` (including e.g. `!fir.array`). Note that `!fir.complex` inside a `!fir.box` falls under case 1. above (i.e. it's a special case regardless of the wrapping type). This is part of the upstreaming effort from the `!fir-dev` branch in [1]. Differential Revision: https://reviews.llvm.org/D114159 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
2021-11-17 10:03:19 +00:00
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::AbsentOp absent, OpAdaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
mlir::Type ty = convertType(absent.getType());
[flang][extension] support concatenation with absent optional (#112678) Fix #112593 by adding support in lowering to concatenation with an absent optional _assumed length_ dummy argument because: 1. Most compilers seem to support it (most likely by accident). 2. This actually makes the compiler codegen simpler. Codegen was going out of its way to poke the LLVM optimizer bear by producing an undef argument for the length. I insist on the fact that no compiler support this with _explicit length_ optional arguments and the executable will segfault and I would discourage users from using that "feature" because runtime checks for bad optional dereference will kick when used (For instance, "nagfor -C=present" will produce an executable that abort with an error message . Flang does not have such runtime check option so far). Hence, I am not updating the Extensions.md document because this is not something I think we should advertise.
2024-10-17 13:25:09 +02:00
rewriter.replaceOpWithNewOp<mlir::LLVM::ZeroOp>(absent, ty);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
};
[flang][codegen] Add a conversion for `!fir.coordinate_of` - part 1 This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `!fir.coordinate_of` into a sequence of LLVM MLIR instructions. The following cases are currently supported: 1. the input object is a `!fir.complex` (wrapped in e.g. `!fir.ref` or `!fir.box`) 2. the input object is wrapped in a `!fir.box` (including e.g. `!fir.array`). Note that `!fir.complex` inside a `!fir.box` falls under case 1. above (i.e. it's a special case regardless of the wrapping type). This is part of the upstreaming effort from the `!fir-dev` branch in [1]. Differential Revision: https://reviews.llvm.org/D114159 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
2021-11-17 10:03:19 +00:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
//
// Primitive operations on Complex types
//
[flang][codegen] Add a conversion for `!fir.coordinate_of` - part 1 This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `!fir.coordinate_of` into a sequence of LLVM MLIR instructions. The following cases are currently supported: 1. the input object is a `!fir.complex` (wrapped in e.g. `!fir.ref` or `!fir.box`) 2. the input object is wrapped in a `!fir.box` (including e.g. `!fir.array`). Note that `!fir.complex` inside a `!fir.box` falls under case 1. above (i.e. it's a special case regardless of the wrapping type). This is part of the upstreaming effort from the `!fir-dev` branch in [1]. Differential Revision: https://reviews.llvm.org/D114159 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
2021-11-17 10:03:19 +00:00
[flang] Add fastmath attributes to complex arithmetic (#70690) Propagate fast math flags through complex number lowering (when lowering fir.*c directly to llvm floating point operations). The lowering path through the MLIR complex dialect is unchanged. This leads to a small improvement in spec2017 fotonik3d_r.
2023-10-31 16:15:13 +00:00
template <typename OPTY>
static inline mlir::LLVM::FastmathFlagsAttr getLLVMFMFAttr(OPTY op) {
return mlir::LLVM::FastmathFlagsAttr::get(
op.getContext(),
mlir::arith::convertArithFastMathFlagsToLLVM(op.getFastmath()));
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// Generate inline code for complex addition/subtraction
template <typename LLVMOP, typename OPTY>
static mlir::LLVM::InsertValueOp
complexSum(OPTY sumop, mlir::ValueRange opnds,
mlir::ConversionPatternRewriter &rewriter,
[mlir][Conversion] Store const type converter in ConversionPattern ConversionPatterns do not (and should not) modify the type converter that they are using. * Make `ConversionPattern::typeConverter` const. * Make member functions of the `LLVMTypeConverter` const. * Conversion patterns take a const type converter. * Various helper functions (that are called from patterns) now also take a const type converter. Differential Revision: https://reviews.llvm.org/D157601
2023-08-14 08:40:13 +02:00
const fir::LLVMTypeConverter &lowering) {
[flang] Add fastmath attributes to complex arithmetic (#70690) Propagate fast math flags through complex number lowering (when lowering fir.*c directly to llvm floating point operations). The lowering path through the MLIR complex dialect is unchanged. This leads to a small improvement in spec2017 fotonik3d_r.
2023-10-31 16:15:13 +00:00
mlir::LLVM::FastmathFlagsAttr fmf = getLLVMFMFAttr(sumop);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::Value a = opnds[0];
mlir::Value b = opnds[1];
auto loc = sumop.getLoc();
mlir::Type eleTy = lowering.convertType(getComplexEleTy(sumop.getType()));
mlir::Type ty = lowering.convertType(sumop.getType());
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
auto x0 = rewriter.create<mlir::LLVM::ExtractValueOp>(loc, a, 0);
auto y0 = rewriter.create<mlir::LLVM::ExtractValueOp>(loc, a, 1);
auto x1 = rewriter.create<mlir::LLVM::ExtractValueOp>(loc, b, 0);
auto y1 = rewriter.create<mlir::LLVM::ExtractValueOp>(loc, b, 1);
[flang] Add fastmath attributes to complex arithmetic (#70690) Propagate fast math flags through complex number lowering (when lowering fir.*c directly to llvm floating point operations). The lowering path through the MLIR complex dialect is unchanged. This leads to a small improvement in spec2017 fotonik3d_r.
2023-10-31 16:15:13 +00:00
auto rx = rewriter.create<LLVMOP>(loc, eleTy, x0, x1, fmf);
auto ry = rewriter.create<LLVMOP>(loc, eleTy, y0, y1, fmf);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
auto r0 = rewriter.create<mlir::LLVM::UndefOp>(loc, ty);
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
auto r1 = rewriter.create<mlir::LLVM::InsertValueOp>(loc, r0, rx, 0);
return rewriter.create<mlir::LLVM::InsertValueOp>(loc, r1, ry, 1);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
} // namespace
[flang][codegen] Add a conversion for `!fir.coordinate_of` - part 1 This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `!fir.coordinate_of` into a sequence of LLVM MLIR instructions. The following cases are currently supported: 1. the input object is a `!fir.complex` (wrapped in e.g. `!fir.ref` or `!fir.box`) 2. the input object is wrapped in a `!fir.box` (including e.g. `!fir.array`). Note that `!fir.complex` inside a `!fir.box` falls under case 1. above (i.e. it's a special case regardless of the wrapping type). This is part of the upstreaming effort from the `!fir-dev` branch in [1]. Differential Revision: https://reviews.llvm.org/D114159 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
2021-11-17 10:03:19 +00:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
namespace {
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct AddcOpConversion : public fir::FIROpConversion<fir::AddcOp> {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::AddcOp addc, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
// given: (x + iy) + (x' + iy')
// result: (x + x') + i(y + y')
auto r = complexSum<mlir::LLVM::FAddOp>(addc, adaptor.getOperands(),
rewriter, lowerTy());
rewriter.replaceOp(addc, r.getResult());
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[flang][codegen] Add a conversion for `!fir.coordinate_of` - part 1 This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `!fir.coordinate_of` into a sequence of LLVM MLIR instructions. The following cases are currently supported: 1. the input object is a `!fir.complex` (wrapped in e.g. `!fir.ref` or `!fir.box`) 2. the input object is wrapped in a `!fir.box` (including e.g. `!fir.array`). Note that `!fir.complex` inside a `!fir.box` falls under case 1. above (i.e. it's a special case regardless of the wrapping type). This is part of the upstreaming effort from the `!fir-dev` branch in [1]. Differential Revision: https://reviews.llvm.org/D114159 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
2021-11-17 10:03:19 +00:00
}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
};
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct SubcOpConversion : public fir::FIROpConversion<fir::SubcOp> {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
using FIROpConversion::FIROpConversion;
[flang][codegen] Add a conversion for `!fir.coordinate_of` - part 1 This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `!fir.coordinate_of` into a sequence of LLVM MLIR instructions. The following cases are currently supported: 1. the input object is a `!fir.complex` (wrapped in e.g. `!fir.ref` or `!fir.box`) 2. the input object is wrapped in a `!fir.box` (including e.g. `!fir.array`). Note that `!fir.complex` inside a `!fir.box` falls under case 1. above (i.e. it's a special case regardless of the wrapping type). This is part of the upstreaming effort from the `!fir-dev` branch in [1]. Differential Revision: https://reviews.llvm.org/D114159 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
2021-11-17 10:03:19 +00:00
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::SubcOp subc, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
// given: (x + iy) - (x' + iy')
// result: (x - x') + i(y - y')
auto r = complexSum<mlir::LLVM::FSubOp>(subc, adaptor.getOperands(),
rewriter, lowerTy());
rewriter.replaceOp(subc, r.getResult());
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
};
[flang][codegen] Add a conversion for `fir.coordinate_of` - part 2 This patch extends the `FIRToLLVMLowering` pass in Flang by extending the hook to transform `fir.coordinate_of` into a sequence of LLVM MLIR instructions (i.e. `CoordinateOpConversion::doRewrite`). The following case is added: 3.1 the input object is inside `!fir.ref` (e.g. `!fir.ref<!fir.array>` or `!fir.ref<!fir.type>`). 3.2 the input object is inside `!fir.ptr` (e.g. `!fir.ptr<!fir.array>` or `!fir.ptr<!fir.type>`). From the point of view of the conversion, 3.1 and 3.2 are currently identical. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Originally written by: Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com> Depends on: D114159 Differential Revision: https://reviews.llvm.org/D115333
2021-11-23 18:13:51 +00:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// Inlined complex multiply
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct MulcOpConversion : public fir::FIROpConversion<fir::MulcOp> {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
using FIROpConversion::FIROpConversion;
[flang][codegen] Add a conversion for `fir.coordinate_of` - part 2 This patch extends the `FIRToLLVMLowering` pass in Flang by extending the hook to transform `fir.coordinate_of` into a sequence of LLVM MLIR instructions (i.e. `CoordinateOpConversion::doRewrite`). The following case is added: 3.1 the input object is inside `!fir.ref` (e.g. `!fir.ref<!fir.array>` or `!fir.ref<!fir.type>`). 3.2 the input object is inside `!fir.ptr` (e.g. `!fir.ptr<!fir.array>` or `!fir.ptr<!fir.type>`). From the point of view of the conversion, 3.1 and 3.2 are currently identical. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Originally written by: Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com> Depends on: D114159 Differential Revision: https://reviews.llvm.org/D115333
2021-11-23 18:13:51 +00:00
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::MulcOp mulc, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
// TODO: Can we use a call to __muldc3 ?
// given: (x + iy) * (x' + iy')
// result: (xx'-yy')+i(xy'+yx')
[flang] Add fastmath attributes to complex arithmetic (#70690) Propagate fast math flags through complex number lowering (when lowering fir.*c directly to llvm floating point operations). The lowering path through the MLIR complex dialect is unchanged. This leads to a small improvement in spec2017 fotonik3d_r.
2023-10-31 16:15:13 +00:00
mlir::LLVM::FastmathFlagsAttr fmf = getLLVMFMFAttr(mulc);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::Value a = adaptor.getOperands()[0];
mlir::Value b = adaptor.getOperands()[1];
auto loc = mulc.getLoc();
mlir::Type eleTy = convertType(getComplexEleTy(mulc.getType()));
mlir::Type ty = convertType(mulc.getType());
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
auto x0 = rewriter.create<mlir::LLVM::ExtractValueOp>(loc, a, 0);
auto y0 = rewriter.create<mlir::LLVM::ExtractValueOp>(loc, a, 1);
auto x1 = rewriter.create<mlir::LLVM::ExtractValueOp>(loc, b, 0);
auto y1 = rewriter.create<mlir::LLVM::ExtractValueOp>(loc, b, 1);
[flang] Add fastmath attributes to complex arithmetic (#70690) Propagate fast math flags through complex number lowering (when lowering fir.*c directly to llvm floating point operations). The lowering path through the MLIR complex dialect is unchanged. This leads to a small improvement in spec2017 fotonik3d_r.
2023-10-31 16:15:13 +00:00
auto xx = rewriter.create<mlir::LLVM::FMulOp>(loc, eleTy, x0, x1, fmf);
auto yx = rewriter.create<mlir::LLVM::FMulOp>(loc, eleTy, y0, x1, fmf);
auto xy = rewriter.create<mlir::LLVM::FMulOp>(loc, eleTy, x0, y1, fmf);
auto ri = rewriter.create<mlir::LLVM::FAddOp>(loc, eleTy, xy, yx, fmf);
auto yy = rewriter.create<mlir::LLVM::FMulOp>(loc, eleTy, y0, y1, fmf);
auto rr = rewriter.create<mlir::LLVM::FSubOp>(loc, eleTy, xx, yy, fmf);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
auto ra = rewriter.create<mlir::LLVM::UndefOp>(loc, ty);
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
auto r1 = rewriter.create<mlir::LLVM::InsertValueOp>(loc, ra, rr, 0);
auto r0 = rewriter.create<mlir::LLVM::InsertValueOp>(loc, r1, ri, 1);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
rewriter.replaceOp(mulc, r0.getResult());
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
};
[flang][codegen] Add a conversion for `fir.coordinate_of` - part 2 This patch extends the `FIRToLLVMLowering` pass in Flang by extending the hook to transform `fir.coordinate_of` into a sequence of LLVM MLIR instructions (i.e. `CoordinateOpConversion::doRewrite`). The following case is added: 3.1 the input object is inside `!fir.ref` (e.g. `!fir.ref<!fir.array>` or `!fir.ref<!fir.type>`). 3.2 the input object is inside `!fir.ptr` (e.g. `!fir.ptr<!fir.array>` or `!fir.ptr<!fir.type>`). From the point of view of the conversion, 3.1 and 3.2 are currently identical. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Originally written by: Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com> Depends on: D114159 Differential Revision: https://reviews.llvm.org/D115333
2021-11-23 18:13:51 +00:00
Revert "[Flang] Change fir.divc to perform library call rather than generate inline operations." This reverts commit a7bb8e273f433cceeb547e87d04114178573496a. Revertin since this runs into an ABI issue.
2023-04-18 11:08:16 +00:00
/// Inlined complex division
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct DivcOpConversion : public fir::FIROpConversion<fir::DivcOp> {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
using FIROpConversion::FIROpConversion;
[flang][codegen] Add a conversion for `fir.coordinate_of` - part 2 This patch extends the `FIRToLLVMLowering` pass in Flang by extending the hook to transform `fir.coordinate_of` into a sequence of LLVM MLIR instructions (i.e. `CoordinateOpConversion::doRewrite`). The following case is added: 3.1 the input object is inside `!fir.ref` (e.g. `!fir.ref<!fir.array>` or `!fir.ref<!fir.type>`). 3.2 the input object is inside `!fir.ptr` (e.g. `!fir.ptr<!fir.array>` or `!fir.ptr<!fir.type>`). From the point of view of the conversion, 3.1 and 3.2 are currently identical. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Originally written by: Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com> Depends on: D114159 Differential Revision: https://reviews.llvm.org/D115333
2021-11-23 18:13:51 +00:00
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::DivcOp divc, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
Revert "[Flang] Change fir.divc to perform library call rather than generate inline operations." This reverts commit a7bb8e273f433cceeb547e87d04114178573496a. Revertin since this runs into an ABI issue.
2023-04-18 11:08:16 +00:00
// TODO: Can we use a call to __divdc3 instead?
// Just generate inline code for now.
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
// given: (x + iy) / (x' + iy')
// result: ((xx'+yy')/d) + i((yx'-xy')/d) where d = x'x' + y'y'
[flang] Add fastmath attributes to complex arithmetic (#70690) Propagate fast math flags through complex number lowering (when lowering fir.*c directly to llvm floating point operations). The lowering path through the MLIR complex dialect is unchanged. This leads to a small improvement in spec2017 fotonik3d_r.
2023-10-31 16:15:13 +00:00
mlir::LLVM::FastmathFlagsAttr fmf = getLLVMFMFAttr(divc);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
mlir::Value a = adaptor.getOperands()[0];
mlir::Value b = adaptor.getOperands()[1];
auto loc = divc.getLoc();
mlir::Type eleTy = convertType(getComplexEleTy(divc.getType()));
Revert "[Flang] Change fir.divc to perform library call rather than generate inline operations." This reverts commit a7bb8e273f433cceeb547e87d04114178573496a. Revertin since this runs into an ABI issue.
2023-04-18 11:08:16 +00:00
mlir::Type ty = convertType(divc.getType());
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
auto x0 = rewriter.create<mlir::LLVM::ExtractValueOp>(loc, a, 0);
auto y0 = rewriter.create<mlir::LLVM::ExtractValueOp>(loc, a, 1);
auto x1 = rewriter.create<mlir::LLVM::ExtractValueOp>(loc, b, 0);
auto y1 = rewriter.create<mlir::LLVM::ExtractValueOp>(loc, b, 1);
[flang] Add fastmath attributes to complex arithmetic (#70690) Propagate fast math flags through complex number lowering (when lowering fir.*c directly to llvm floating point operations). The lowering path through the MLIR complex dialect is unchanged. This leads to a small improvement in spec2017 fotonik3d_r.
2023-10-31 16:15:13 +00:00
auto xx = rewriter.create<mlir::LLVM::FMulOp>(loc, eleTy, x0, x1, fmf);
auto x1x1 = rewriter.create<mlir::LLVM::FMulOp>(loc, eleTy, x1, x1, fmf);
auto yx = rewriter.create<mlir::LLVM::FMulOp>(loc, eleTy, y0, x1, fmf);
auto xy = rewriter.create<mlir::LLVM::FMulOp>(loc, eleTy, x0, y1, fmf);
auto yy = rewriter.create<mlir::LLVM::FMulOp>(loc, eleTy, y0, y1, fmf);
auto y1y1 = rewriter.create<mlir::LLVM::FMulOp>(loc, eleTy, y1, y1, fmf);
auto d = rewriter.create<mlir::LLVM::FAddOp>(loc, eleTy, x1x1, y1y1, fmf);
auto rrn = rewriter.create<mlir::LLVM::FAddOp>(loc, eleTy, xx, yy, fmf);
auto rin = rewriter.create<mlir::LLVM::FSubOp>(loc, eleTy, yx, xy, fmf);
auto rr = rewriter.create<mlir::LLVM::FDivOp>(loc, eleTy, rrn, d, fmf);
auto ri = rewriter.create<mlir::LLVM::FDivOp>(loc, eleTy, rin, d, fmf);
Revert "[Flang] Change fir.divc to perform library call rather than generate inline operations." This reverts commit a7bb8e273f433cceeb547e87d04114178573496a. Revertin since this runs into an ABI issue.
2023-04-18 11:08:16 +00:00
auto ra = rewriter.create<mlir::LLVM::UndefOp>(loc, ty);
auto r1 = rewriter.create<mlir::LLVM::InsertValueOp>(loc, ra, rr, 0);
auto r0 = rewriter.create<mlir::LLVM::InsertValueOp>(loc, r1, ri, 1);
rewriter.replaceOp(divc, r0.getResult());
return mlir::success();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
};
[flang][codegen] Add a conversion for `fir.coordinate_of` - part 2 This patch extends the `FIRToLLVMLowering` pass in Flang by extending the hook to transform `fir.coordinate_of` into a sequence of LLVM MLIR instructions (i.e. `CoordinateOpConversion::doRewrite`). The following case is added: 3.1 the input object is inside `!fir.ref` (e.g. `!fir.ref<!fir.array>` or `!fir.ref<!fir.type>`). 3.2 the input object is inside `!fir.ptr` (e.g. `!fir.ptr<!fir.array>` or `!fir.ptr<!fir.type>`). From the point of view of the conversion, 3.1 and 3.2 are currently identical. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Originally written by: Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com> Depends on: D114159 Differential Revision: https://reviews.llvm.org/D115333
2021-11-23 18:13:51 +00:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// Inlined complex negation
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct NegcOpConversion : public fir::FIROpConversion<fir::NegcOp> {
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
using FIROpConversion::FIROpConversion;
[flang][codegen] Add a conversion for `fir.coordinate_of` - part 2 This patch extends the `FIRToLLVMLowering` pass in Flang by extending the hook to transform `fir.coordinate_of` into a sequence of LLVM MLIR instructions (i.e. `CoordinateOpConversion::doRewrite`). The following case is added: 3.1 the input object is inside `!fir.ref` (e.g. `!fir.ref<!fir.array>` or `!fir.ref<!fir.type>`). 3.2 the input object is inside `!fir.ptr` (e.g. `!fir.ptr<!fir.array>` or `!fir.ptr<!fir.type>`). From the point of view of the conversion, 3.1 and 3.2 are currently identical. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Originally written by: Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com> Depends on: D114159 Differential Revision: https://reviews.llvm.org/D115333
2021-11-23 18:13:51 +00:00
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(fir::NegcOp neg, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
// given: -(x + iy)
// result: -x - iy
auto eleTy = convertType(getComplexEleTy(neg.getType()));
auto loc = neg.getLoc();
mlir::Value o0 = adaptor.getOperands()[0];
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
auto rp = rewriter.create<mlir::LLVM::ExtractValueOp>(loc, o0, 0);
auto ip = rewriter.create<mlir::LLVM::ExtractValueOp>(loc, o0, 1);
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
auto nrp = rewriter.create<mlir::LLVM::FNegOp>(loc, eleTy, rp);
auto nip = rewriter.create<mlir::LLVM::FNegOp>(loc, eleTy, ip);
[mlir][LLVMIR] "Modernize" Insert/ExtractValueOp This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2022-08-09 22:07:35 -04:00
auto r = rewriter.create<mlir::LLVM::InsertValueOp>(loc, o0, nrp, 0);
rewriter.replaceOpWithNewOp<mlir::LLVM::InsertValueOp>(neg, r, nip, 1);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
};
[flang][codegen] Add a conversion for `fir.coordinate_of` - part 2 This patch extends the `FIRToLLVMLowering` pass in Flang by extending the hook to transform `fir.coordinate_of` into a sequence of LLVM MLIR instructions (i.e. `CoordinateOpConversion::doRewrite`). The following case is added: 3.1 the input object is inside `!fir.ref` (e.g. `!fir.ref<!fir.array>` or `!fir.ref<!fir.type>`). 3.2 the input object is inside `!fir.ptr` (e.g. `!fir.ptr<!fir.array>` or `!fir.ptr<!fir.type>`). From the point of view of the conversion, 3.1 and 3.2 are currently identical. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Originally written by: Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com> Depends on: D114159 Differential Revision: https://reviews.llvm.org/D115333
2021-11-23 18:13:51 +00:00
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct BoxOffsetOpConversion : public fir::FIROpConversion<fir::BoxOffsetOp> {
[flang] add fir.box_offset operation (#73641) This operation allows computing the address of descriptor fields. It is needed to help attaching descriptors in OpenMP/OpenACC target region. The pointers inside the descriptor structure must be mapped too, but the fir.box is abstract, so these fields cannot be computed with fir.coordinate_of. To preserve the abstraction of the descriptor layout in FIR, introduce an operation specifically to !fir.ref<fir.box<>> address fields based on field names (base_addr or derived_type).
2023-11-29 10:27:27 +01:00
using FIROpConversion::FIROpConversion;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[flang] add fir.box_offset operation (#73641) This operation allows computing the address of descriptor fields. It is needed to help attaching descriptors in OpenMP/OpenACC target region. The pointers inside the descriptor structure must be mapped too, but the fir.box is abstract, so these fields cannot be computed with fir.coordinate_of. To preserve the abstraction of the descriptor layout in FIR, introduce an operation specifically to !fir.ref<fir.box<>> address fields based on field names (base_addr or derived_type).
2023-11-29 10:27:27 +01:00
matchAndRewrite(fir::BoxOffsetOp boxOffset, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const override {
mlir::Type pty = ::getLlvmPtrType(boxOffset.getContext());
mlir::Type boxType = fir::unwrapRefType(boxOffset.getBoxRef().getType());
mlir::Type llvmBoxTy =
lowerTy().convertBoxTypeAsStruct(mlir::cast<fir::BaseBoxType>(boxType));
[flang] fix codegen warning from #73641 (#73808)
2023-11-29 18:00:40 +01:00
int fieldId = boxOffset.getField() == fir::BoxFieldAttr::derived_type
? getTypeDescFieldId(boxType)
: kAddrPosInBox;
[flang] add fir.box_offset operation (#73641) This operation allows computing the address of descriptor fields. It is needed to help attaching descriptors in OpenMP/OpenACC target region. The pointers inside the descriptor structure must be mapped too, but the fir.box is abstract, so these fields cannot be computed with fir.coordinate_of. To preserve the abstraction of the descriptor layout in FIR, introduce an operation specifically to !fir.ref<fir.box<>> address fields based on field names (base_addr or derived_type).
2023-11-29 10:27:27 +01:00
rewriter.replaceOpWithNewOp<mlir::LLVM::GEPOp>(
boxOffset, pty, llvmBoxTy, adaptor.getBoxRef(),
llvm::ArrayRef<mlir::LLVM::GEPArg>{0, fieldId});
return mlir::success();
}
};
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
/// Conversion pattern for operation that must be dead. The information in these
/// operations is used by other operation. At this point they should not have
/// anymore uses.
/// These operations are normally dead after the pre-codegen pass.
template <typename FromOp>
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
struct MustBeDeadConversion : public fir::FIROpConversion<FromOp> {
[mlir][Conversion] Store const type converter in ConversionPattern ConversionPatterns do not (and should not) modify the type converter that they are using. * Make `ConversionPattern::typeConverter` const. * Make member functions of the `LLVMTypeConverter` const. * Conversion patterns take a const type converter. * Various helper functions (that are called from patterns) now also take a const type converter. Differential Revision: https://reviews.llvm.org/D157601
2023-08-14 08:40:13 +02:00
explicit MustBeDeadConversion(const fir::LLVMTypeConverter &lowering,
[flang] Lowering fir.dispatch in the polymorphic op pass Differential revision: https://reviews.llvm.org/D146594
2023-03-21 16:32:26 -07:00
const fir::FIRToLLVMPassOptions &options)
[flang][NFC] Extract FIROpConversion to its own files (#86213) This PR extracts `FIROpConversion` and `FIROpAndTypeConversion` templated base patterns to a header file. All the functions from FIROpConversion that do not require the template argument are moved to a base class named `ConvertFIRToLLVMPattern`. This move is done so the `FIROpConversion` pattern and all its utility functions can be reused outside of the codegen pass. For the most part the code is only moved to the new files and not modified. The only update is that addition of the PatternBenefit argument with a default value to the constructor so it can be forwarded to the `ConversionPattern` ctor. This split is done in a similar way for the `ConvertOpToLLVMPattern` base pattern that is based on the `ConvertToLLVMPattern` base class in `mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
2024-03-22 12:56:45 -07:00
: fir::FIROpConversion<FromOp>(lowering, options) {}
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
using OpAdaptor = typename FromOp::Adaptor;
[flang][codegen] Add a conversion for `fir.coordinate_of` - part 2 This patch extends the `FIRToLLVMLowering` pass in Flang by extending the hook to transform `fir.coordinate_of` into a sequence of LLVM MLIR instructions (i.e. `CoordinateOpConversion::doRewrite`). The following case is added: 3.1 the input object is inside `!fir.ref` (e.g. `!fir.ref<!fir.array>` or `!fir.ref<!fir.type>`). 3.2 the input object is inside `!fir.ptr` (e.g. `!fir.ptr<!fir.array>` or `!fir.ptr<!fir.type>`). From the point of view of the conversion, 3.1 and 3.2 are currently identical. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Originally written by: Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com> Depends on: D114159 Differential Revision: https://reviews.llvm.org/D115333
2021-11-23 18:13:51 +00:00
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
matchAndRewrite(FromOp op, OpAdaptor adaptor,
mlir::ConversionPatternRewriter &rewriter) const final {
if (!op->getUses().empty())
return rewriter.notifyMatchFailure(op, "op must be dead");
rewriter.eraseOp(op);
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
return mlir::success();
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
}
};
[flang][codegen] Add a conversion for `fir.coordinate_of` - part 2 This patch extends the `FIRToLLVMLowering` pass in Flang by extending the hook to transform `fir.coordinate_of` into a sequence of LLVM MLIR instructions (i.e. `CoordinateOpConversion::doRewrite`). The following case is added: 3.1 the input object is inside `!fir.ref` (e.g. `!fir.ref<!fir.array>` or `!fir.ref<!fir.type>`). 3.2 the input object is inside `!fir.ptr` (e.g. `!fir.ptr<!fir.array>` or `!fir.ptr<!fir.type>`). From the point of view of the conversion, 3.1 and 3.2 are currently identical. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Originally written by: Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com> Depends on: D114159 Differential Revision: https://reviews.llvm.org/D115333
2021-11-23 18:13:51 +00:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
struct ShapeOpConversion : public MustBeDeadConversion<fir::ShapeOp> {
using MustBeDeadConversion::MustBeDeadConversion;
};
[flang][codegen] Add a conversion for `fir.coordinate_of` - part 2 This patch extends the `FIRToLLVMLowering` pass in Flang by extending the hook to transform `fir.coordinate_of` into a sequence of LLVM MLIR instructions (i.e. `CoordinateOpConversion::doRewrite`). The following case is added: 3.1 the input object is inside `!fir.ref` (e.g. `!fir.ref<!fir.array>` or `!fir.ref<!fir.type>`). 3.2 the input object is inside `!fir.ptr` (e.g. `!fir.ptr<!fir.array>` or `!fir.ptr<!fir.type>`). From the point of view of the conversion, 3.1 and 3.2 are currently identical. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Originally written by: Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com> Depends on: D114159 Differential Revision: https://reviews.llvm.org/D115333
2021-11-23 18:13:51 +00:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
struct ShapeShiftOpConversion : public MustBeDeadConversion<fir::ShapeShiftOp> {
using MustBeDeadConversion::MustBeDeadConversion;
};
[flang][codegen] Add a conversion for `fir.coordinate_of` - part 2 This patch extends the `FIRToLLVMLowering` pass in Flang by extending the hook to transform `fir.coordinate_of` into a sequence of LLVM MLIR instructions (i.e. `CoordinateOpConversion::doRewrite`). The following case is added: 3.1 the input object is inside `!fir.ref` (e.g. `!fir.ref<!fir.array>` or `!fir.ref<!fir.type>`). 3.2 the input object is inside `!fir.ptr` (e.g. `!fir.ptr<!fir.array>` or `!fir.ptr<!fir.type>`). From the point of view of the conversion, 3.1 and 3.2 are currently identical. This is part of the upstreaming effort from the `fir-dev` branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Originally written by: Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com> Depends on: D114159 Differential Revision: https://reviews.llvm.org/D115333
2021-11-23 18:13:51 +00:00
[Flang] NFC: Rearrange conversion patterns in Codegen.cpp Minor rearrangment in the order of conversion patterns to identify differences. Reviewed By: clementval, schweitz Differential Revision: https://reviews.llvm.org/D120721
2022-03-02 11:22:07 +00:00
struct ShiftOpConversion : public MustBeDeadConversion<fir::ShiftOp> {
using MustBeDeadConversion::MustBeDeadConversion;
};
struct SliceOpConversion : public MustBeDeadConversion<fir::SliceOp> {
using MustBeDeadConversion::MustBeDeadConversion;
[flang][codegen] Add a conversion for `!fir.coordinate_of` - part 1 This patch extends the `FIRToLLVMLowering` pass in Flang by adding a hook to transform `!fir.coordinate_of` into a sequence of LLVM MLIR instructions. The following cases are currently supported: 1. the input object is a `!fir.complex` (wrapped in e.g. `!fir.ref` or `!fir.box`) 2. the input object is wrapped in a `!fir.box` (including e.g. `!fir.array`). Note that `!fir.complex` inside a `!fir.box` falls under case 1. above (i.e. it's a special case regardless of the wrapping type). This is part of the upstreaming effort from the `!fir-dev` branch in [1]. Differential Revision: https://reviews.llvm.org/D114159 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
2021-11-17 10:03:19 +00:00
};
[fir] Add base of the FIR to LLVM IR pass This patch adds the base of the FIR to LLVM IR Dialect conversion pass. It currently can convert the following operations: - fir.global - fir.has_value - fir.address_of - fir.undefined This patch is part of the upstreaming effort from fir-dev branch. It does not cover all FIR operations in order to have small patches. Several patches will follow to convert other operations. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D112845
2021-10-29 23:20:50 +02:00
} // namespace
[flang] Rename hypotf on MSVC platforms The single precision `hypot` intrinsic is lowered to a call to the libm `hypotf` function. However, the MSVC runtime lacks a hypotf function and instead uses `_hypotf` (*). This patch tries to find and rewrite calls to `hypotf` if we're on a MSVC platform. Calls to libm functions can be introduced even after lowering (**). Therefore, we try to do the rewriting at the very end of FIR to LLVM lowering. Fixes https://github.com/llvm/llvm-project/issues/57563 (*) More specifically, MSVC's headers define hypotf as an inline function that just calls _hypotf. This works fine for clang, since it will include those headers, but flang only links with the CRT so we don't get a free ride. (**) https://github.com/llvm/llvm-project/blob/56f94ede2af9a327e59fe84dbf8cbbb7bb1dfa79/flang/lib/Optimizer/CodeGen/CodeGen.cpp#L3391 Differential Revision: https://reviews.llvm.org/D135853
2022-10-11 12:38:08 +00:00
namespace {
class RenameMSVCLibmCallees
: public mlir::OpRewritePattern<mlir::LLVM::CallOp> {
public:
using OpRewritePattern::OpRewritePattern;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[flang] Rename hypotf on MSVC platforms The single precision `hypot` intrinsic is lowered to a call to the libm `hypotf` function. However, the MSVC runtime lacks a hypotf function and instead uses `_hypotf` (*). This patch tries to find and rewrite calls to `hypotf` if we're on a MSVC platform. Calls to libm functions can be introduced even after lowering (**). Therefore, we try to do the rewriting at the very end of FIR to LLVM lowering. Fixes https://github.com/llvm/llvm-project/issues/57563 (*) More specifically, MSVC's headers define hypotf as an inline function that just calls _hypotf. This works fine for clang, since it will include those headers, but flang only links with the CRT so we don't get a free ride. (**) https://github.com/llvm/llvm-project/blob/56f94ede2af9a327e59fe84dbf8cbbb7bb1dfa79/flang/lib/Optimizer/CodeGen/CodeGen.cpp#L3391 Differential Revision: https://reviews.llvm.org/D135853
2022-10-11 12:38:08 +00:00
matchAndRewrite(mlir::LLVM::CallOp op,
mlir::PatternRewriter &rewriter) const override {
[mlir][IR] Rename "update root" to "modify op" in rewriter API (#78260) This commit renames 4 pattern rewriter API functions: * `updateRootInPlace` -> `modifyOpInPlace` * `startRootUpdate` -> `startOpModification` * `finalizeRootUpdate` -> `finalizeOpModification` * `cancelRootUpdate` -> `cancelOpModification` The term "root" is a misnomer. The root is the op that a rewrite pattern matches against (https://mlir.llvm.org/docs/PatternRewriter/#root-operation-name-optional). A rewriter must be notified of all in-place op modifications, not just in-place modifications of the root (https://mlir.llvm.org/docs/PatternRewriter/#pattern-rewriter). The old function names were confusing and have contributed to various broken rewrite patterns. Note: The new function names use the term "modify" instead of "update" for consistency with the `RewriterBase::Listener` terminology (`notifyOperationModified`).
2024-01-17 11:08:59 +01:00
rewriter.startOpModification(op);
[flang] Rename hypotf on MSVC platforms The single precision `hypot` intrinsic is lowered to a call to the libm `hypotf` function. However, the MSVC runtime lacks a hypotf function and instead uses `_hypotf` (*). This patch tries to find and rewrite calls to `hypotf` if we're on a MSVC platform. Calls to libm functions can be introduced even after lowering (**). Therefore, we try to do the rewriting at the very end of FIR to LLVM lowering. Fixes https://github.com/llvm/llvm-project/issues/57563 (*) More specifically, MSVC's headers define hypotf as an inline function that just calls _hypotf. This works fine for clang, since it will include those headers, but flang only links with the CRT so we don't get a free ride. (**) https://github.com/llvm/llvm-project/blob/56f94ede2af9a327e59fe84dbf8cbbb7bb1dfa79/flang/lib/Optimizer/CodeGen/CodeGen.cpp#L3391 Differential Revision: https://reviews.llvm.org/D135853
2022-10-11 12:38:08 +00:00
auto callee = op.getCallee();
if (callee)
Use StringRef::operator== instead of StringRef::equals (NFC) (#91864) I'm planning to remove StringRef::equals in favor of StringRef::operator==. - StringRef::operator==/!= outnumber StringRef::equals by a factor of 276 under llvm-project/ in terms of their usage. - The elimination of StringRef::equals brings StringRef closer to std::string_view, which has operator== but not equals. - S == "foo" is more readable than S.equals("foo"), especially for !Long.Expression.equals("str") vs Long.Expression != "str".
2024-05-12 23:08:40 -07:00
if (*callee == "hypotf")
[flang] Rename hypotf on MSVC platforms The single precision `hypot` intrinsic is lowered to a call to the libm `hypotf` function. However, the MSVC runtime lacks a hypotf function and instead uses `_hypotf` (*). This patch tries to find and rewrite calls to `hypotf` if we're on a MSVC platform. Calls to libm functions can be introduced even after lowering (**). Therefore, we try to do the rewriting at the very end of FIR to LLVM lowering. Fixes https://github.com/llvm/llvm-project/issues/57563 (*) More specifically, MSVC's headers define hypotf as an inline function that just calls _hypotf. This works fine for clang, since it will include those headers, but flang only links with the CRT so we don't get a free ride. (**) https://github.com/llvm/llvm-project/blob/56f94ede2af9a327e59fe84dbf8cbbb7bb1dfa79/flang/lib/Optimizer/CodeGen/CodeGen.cpp#L3391 Differential Revision: https://reviews.llvm.org/D135853
2022-10-11 12:38:08 +00:00
op.setCalleeAttr(mlir::SymbolRefAttr::get(op.getContext(), "_hypotf"));
[mlir][IR] Rename "update root" to "modify op" in rewriter API (#78260) This commit renames 4 pattern rewriter API functions: * `updateRootInPlace` -> `modifyOpInPlace` * `startRootUpdate` -> `startOpModification` * `finalizeRootUpdate` -> `finalizeOpModification` * `cancelRootUpdate` -> `cancelOpModification` The term "root" is a misnomer. The root is the op that a rewrite pattern matches against (https://mlir.llvm.org/docs/PatternRewriter/#root-operation-name-optional). A rewriter must be notified of all in-place op modifications, not just in-place modifications of the root (https://mlir.llvm.org/docs/PatternRewriter/#pattern-rewriter). The old function names were confusing and have contributed to various broken rewrite patterns. Note: The new function names use the term "modify" instead of "update" for consistency with the `RewriterBase::Listener` terminology (`notifyOperationModified`).
2024-01-17 11:08:59 +01:00
rewriter.finalizeOpModification(op);
[flang] Rename hypotf on MSVC platforms The single precision `hypot` intrinsic is lowered to a call to the libm `hypotf` function. However, the MSVC runtime lacks a hypotf function and instead uses `_hypotf` (*). This patch tries to find and rewrite calls to `hypotf` if we're on a MSVC platform. Calls to libm functions can be introduced even after lowering (**). Therefore, we try to do the rewriting at the very end of FIR to LLVM lowering. Fixes https://github.com/llvm/llvm-project/issues/57563 (*) More specifically, MSVC's headers define hypotf as an inline function that just calls _hypotf. This works fine for clang, since it will include those headers, but flang only links with the CRT so we don't get a free ride. (**) https://github.com/llvm/llvm-project/blob/56f94ede2af9a327e59fe84dbf8cbbb7bb1dfa79/flang/lib/Optimizer/CodeGen/CodeGen.cpp#L3391 Differential Revision: https://reviews.llvm.org/D135853
2022-10-11 12:38:08 +00:00
return mlir::success();
}
};
class RenameMSVCLibmFuncs
: public mlir::OpRewritePattern<mlir::LLVM::LLVMFuncOp> {
public:
using OpRewritePattern::OpRewritePattern;
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM.
2024-07-02 10:42:33 +01:00
llvm::LogicalResult
[flang] Rename hypotf on MSVC platforms The single precision `hypot` intrinsic is lowered to a call to the libm `hypotf` function. However, the MSVC runtime lacks a hypotf function and instead uses `_hypotf` (*). This patch tries to find and rewrite calls to `hypotf` if we're on a MSVC platform. Calls to libm functions can be introduced even after lowering (**). Therefore, we try to do the rewriting at the very end of FIR to LLVM lowering. Fixes https://github.com/llvm/llvm-project/issues/57563 (*) More specifically, MSVC's headers define hypotf as an inline function that just calls _hypotf. This works fine for clang, since it will include those headers, but flang only links with the CRT so we don't get a free ride. (**) https://github.com/llvm/llvm-project/blob/56f94ede2af9a327e59fe84dbf8cbbb7bb1dfa79/flang/lib/Optimizer/CodeGen/CodeGen.cpp#L3391 Differential Revision: https://reviews.llvm.org/D135853
2022-10-11 12:38:08 +00:00
matchAndRewrite(mlir::LLVM::LLVMFuncOp op,
mlir::PatternRewriter &rewriter) const override {
[mlir][IR] Rename "update root" to "modify op" in rewriter API (#78260) This commit renames 4 pattern rewriter API functions: * `updateRootInPlace` -> `modifyOpInPlace` * `startRootUpdate` -> `startOpModification` * `finalizeRootUpdate` -> `finalizeOpModification` * `cancelRootUpdate` -> `cancelOpModification` The term "root" is a misnomer. The root is the op that a rewrite pattern matches against (https://mlir.llvm.org/docs/PatternRewriter/#root-operation-name-optional). A rewriter must be notified of all in-place op modifications, not just in-place modifications of the root (https://mlir.llvm.org/docs/PatternRewriter/#pattern-rewriter). The old function names were confusing and have contributed to various broken rewrite patterns. Note: The new function names use the term "modify" instead of "update" for consistency with the `RewriterBase::Listener` terminology (`notifyOperationModified`).
2024-01-17 11:08:59 +01:00
rewriter.startOpModification(op);
Use StringRef::operator== instead of StringRef::equals (NFC) (#91864) I'm planning to remove StringRef::equals in favor of StringRef::operator==. - StringRef::operator==/!= outnumber StringRef::equals by a factor of 276 under llvm-project/ in terms of their usage. - The elimination of StringRef::equals brings StringRef closer to std::string_view, which has operator== but not equals. - S == "foo" is more readable than S.equals("foo"), especially for !Long.Expression.equals("str") vs Long.Expression != "str".
2024-05-12 23:08:40 -07:00
if (op.getSymName() == "hypotf")
[flang] Rename hypotf on MSVC platforms The single precision `hypot` intrinsic is lowered to a call to the libm `hypotf` function. However, the MSVC runtime lacks a hypotf function and instead uses `_hypotf` (*). This patch tries to find and rewrite calls to `hypotf` if we're on a MSVC platform. Calls to libm functions can be introduced even after lowering (**). Therefore, we try to do the rewriting at the very end of FIR to LLVM lowering. Fixes https://github.com/llvm/llvm-project/issues/57563 (*) More specifically, MSVC's headers define hypotf as an inline function that just calls _hypotf. This works fine for clang, since it will include those headers, but flang only links with the CRT so we don't get a free ride. (**) https://github.com/llvm/llvm-project/blob/56f94ede2af9a327e59fe84dbf8cbbb7bb1dfa79/flang/lib/Optimizer/CodeGen/CodeGen.cpp#L3391 Differential Revision: https://reviews.llvm.org/D135853
2022-10-11 12:38:08 +00:00
op.setSymNameAttr(rewriter.getStringAttr("_hypotf"));
[mlir][IR] Rename "update root" to "modify op" in rewriter API (#78260) This commit renames 4 pattern rewriter API functions: * `updateRootInPlace` -> `modifyOpInPlace` * `startRootUpdate` -> `startOpModification` * `finalizeRootUpdate` -> `finalizeOpModification` * `cancelRootUpdate` -> `cancelOpModification` The term "root" is a misnomer. The root is the op that a rewrite pattern matches against (https://mlir.llvm.org/docs/PatternRewriter/#root-operation-name-optional). A rewriter must be notified of all in-place op modifications, not just in-place modifications of the root (https://mlir.llvm.org/docs/PatternRewriter/#pattern-rewriter). The old function names were confusing and have contributed to various broken rewrite patterns. Note: The new function names use the term "modify" instead of "update" for consistency with the `RewriterBase::Listener` terminology (`notifyOperationModified`).
2024-01-17 11:08:59 +01:00
rewriter.finalizeOpModification(op);
[flang] Rename hypotf on MSVC platforms The single precision `hypot` intrinsic is lowered to a call to the libm `hypotf` function. However, the MSVC runtime lacks a hypotf function and instead uses `_hypotf` (*). This patch tries to find and rewrite calls to `hypotf` if we're on a MSVC platform. Calls to libm functions can be introduced even after lowering (**). Therefore, we try to do the rewriting at the very end of FIR to LLVM lowering. Fixes https://github.com/llvm/llvm-project/issues/57563 (*) More specifically, MSVC's headers define hypotf as an inline function that just calls _hypotf. This works fine for clang, since it will include those headers, but flang only links with the CRT so we don't get a free ride. (**) https://github.com/llvm/llvm-project/blob/56f94ede2af9a327e59fe84dbf8cbbb7bb1dfa79/flang/lib/Optimizer/CodeGen/CodeGen.cpp#L3391 Differential Revision: https://reviews.llvm.org/D135853
2022-10-11 12:38:08 +00:00
return mlir::success();
}
};
} // namespace
[fir] Add base of the FIR to LLVM IR pass This patch adds the base of the FIR to LLVM IR Dialect conversion pass. It currently can convert the following operations: - fir.global - fir.has_value - fir.address_of - fir.undefined This patch is part of the upstreaming effort from fir-dev branch. It does not cover all FIR operations in order to have small patches. Several patches will follow to convert other operations. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D112845
2021-10-29 23:20:50 +02:00
namespace {
/// Convert FIR dialect to LLVM dialect
///
/// This pass lowers all FIR dialect operations to LLVM IR dialect. An
/// MLIR pass is used to lower residual Std dialect to LLVM IR dialect.
[MLIR] Update pass declarations to new autogenerated files The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow dropping the old infrastructure. Reviewed By: mehdi_amini, rriddle Differential Review: https://reviews.llvm.org/D132838
2022-08-31 10:16:29 +02:00
class FIRToLLVMLowering
: public fir::impl::FIRToLLVMLoweringBase<FIRToLLVMLowering> {
[fir] Add base of the FIR to LLVM IR pass This patch adds the base of the FIR to LLVM IR Dialect conversion pass. It currently can convert the following operations: - fir.global - fir.has_value - fir.address_of - fir.undefined This patch is part of the upstreaming effort from fir-dev branch. It does not cover all FIR operations in order to have small patches. Several patches will follow to convert other operations. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D112845
2021-10-29 23:20:50 +02:00
public:
[flang] Support PDT type descriptors in codegen This change updates the mapping of derived types and type descriptor object names to support kind parametrized derived types (PDT). It moves the custom name mapping to the internal name utility. To improve robustness and error reporting, type descriptors are also now required to be generated in all compilation unit that manipulates derived types. The previous codegen relied on the fact that descriptors not defined in the current FIR module were available externally. Errors with missing type descriptors were only caught at link time. This patch makes derived type definition mandatory, except if the derived types are expected to not have derived type descriptors (builtin types), or if the newly added debug switch `--ignore-missing-type-desc` is set. In those cases, a null pointer is used as type descriptor pointer. The debug switch intends to help testing FIR to LLVM passes without having to bother providing type descriptor data structures that are normally built by the front-end. Differential Revision: https://reviews.llvm.org/D120804
2022-03-03 10:07:34 +01:00
FIRToLLVMLowering() = default;
FIRToLLVMLowering(fir::FIRToLLVMPassOptions options) : options{options} {}
[fir] Add base of the FIR to LLVM IR pass This patch adds the base of the FIR to LLVM IR Dialect conversion pass. It currently can convert the following operations: - fir.global - fir.has_value - fir.address_of - fir.undefined This patch is part of the upstreaming effort from fir-dev branch. It does not cover all FIR operations in order to have small patches. Several patches will follow to convert other operations. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D112845
2021-10-29 23:20:50 +02:00
mlir::ModuleOp getModule() { return getOperation(); }
void runOnOperation() override final {
[fir] Add complex operations conversion from FIR LLVM IR This patch add conversion for primitive operations on complex types. - fir.addc - fir.subc - fir.mulc - fir.divc - fir.negc This adds also the type conversion for !fir.complex<KIND> type. This patch is part of the upstreaming effort from fir-dev branch. This patch was updated to avoid failure on windows buildbot. Flang codegen does not support windows target so we force the test to use a known target instead. Reviewed By: kiranchandramohan, rovka Differential Revision: https://reviews.llvm.org/D113434 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 14:15:07 +01:00
auto mod = getModule();
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
if (!forcedTargetTriple.empty())
[fir] Add complex operations conversion from FIR LLVM IR This patch add conversion for primitive operations on complex types. - fir.addc - fir.subc - fir.mulc - fir.divc - fir.negc This adds also the type conversion for !fir.complex<KIND> type. This patch is part of the upstreaming effort from fir-dev branch. This patch was updated to avoid failure on windows buildbot. Flang codegen does not support windows target so we force the test to use a known target instead. Reviewed By: kiranchandramohan, rovka Differential Revision: https://reviews.llvm.org/D113434 Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-11-09 14:15:07 +01:00
fir::setTargetTriple(mod, forcedTargetTriple);
[Flang][MLIR] Add basic initial support for alloca and program address space handling in FIR->LLVMIR codegen (#77518) This is a slightly more slimmed down and up-to-date version of the older PR from here: https://reviews.llvm.org/D144203, written by @jsjodin, which has already under gone some review. This PR places allocas in the alloca address space specified by the provided data layout (default is 0 for all address spaces, unless explicitly specified by the layout), and then will cast these alloca's to the program address space if this address space is different from the allocation address space. For most architectures data layouts, this will be a no-op, as they have a flat address space. But in the case of AMDGPU it will result in allocas being placed in the correct address space (5, private), and then casted into the correct program address space (0, generic). This results in correct (partially, a follow up PR will be forthcoming soon) generation of allocations inside of device code. This PR is in addition to the work by @skatrak in this PR: https://github.com/llvm/llvm-project/pull/69599 and adds seperate and neccesary functionality of casting alloca's from their address space to the program address space, both are independent PRs, although there is some minor overlap e.g. this PR incorporates some of the useful helper functions from 69599, so whichever lands first will need a minor rebase. Co-author: jsjodin
2024-01-17 17:37:16 +01:00
if (!forcedDataLayout.empty()) {
llvm::DataLayout dl(forcedDataLayout);
fir::support::setMLIRDataLayout(mod, dl);
}
[Flang][Lower] Attach target_cpu and target_features attributes to MLIR functions (#78289) This patch forwards the target CPU and features information from the Flang frontend to MLIR func.func operation attributes, which are later used to populate the target_cpu and target_features llvm.func attributes. This is achieved in two stages: 1. Introduce the `fir.target_cpu` and `fir.target_features` module attributes with information from the target machine immediately after the initial creation of the MLIR module in the lowering bridge. 2. Update the target rewrite flang pass to get this information from the module and pass it along to all func.func MLIR operations, respectively as attributes named `target_cpu` and `target_features`. These attributes will be automatically picked up during Func to LLVM dialect lowering and used to initialize the corresponding llvm.func named attributes. The target rewrite and FIR to LLVM lowering passes are updated with the ability to override these module attributes, and the `CodeGenSpecifics` optimizer class is augmented to make this information available to target-specific MLIR transformations. This completes a full flow by which target CPU and features make it all the way from compiler options to LLVM IR function attributes.
2024-01-30 13:45:56 +00:00
if (!forcedTargetCPU.empty())
fir::setTargetCPU(mod, forcedTargetCPU);
Add basic -mtune support (#98517) Initial implementation for the -mtune flag in Flang. This PR is a clean version of PR #96688, which is a re-land of PR #95043
2024-07-16 09:48:24 -06:00
if (!forcedTuneCPU.empty())
fir::setTuneCPU(mod, forcedTuneCPU);
[Flang][Lower] Attach target_cpu and target_features attributes to MLIR functions (#78289) This patch forwards the target CPU and features information from the Flang frontend to MLIR func.func operation attributes, which are later used to populate the target_cpu and target_features llvm.func attributes. This is achieved in two stages: 1. Introduce the `fir.target_cpu` and `fir.target_features` module attributes with information from the target machine immediately after the initial creation of the MLIR module in the lowering bridge. 2. Update the target rewrite flang pass to get this information from the module and pass it along to all func.func MLIR operations, respectively as attributes named `target_cpu` and `target_features`. These attributes will be automatically picked up during Func to LLVM dialect lowering and used to initialize the corresponding llvm.func named attributes. The target rewrite and FIR to LLVM lowering passes are updated with the ability to override these module attributes, and the `CodeGenSpecifics` optimizer class is augmented to make this information available to target-specific MLIR transformations. This completes a full flow by which target CPU and features make it all the way from compiler options to LLVM IR function attributes.
2024-01-30 13:45:56 +00:00
if (!forcedTargetFeatures.empty())
fir::setTargetFeatures(mod, forcedTargetFeatures);
[RFC][flang] Replace special symbols in uniqued global names. (#104859) This change addresses more "issues" as the one resolved in #71338. Some targets (e.g. NVPTX) do not accept global names containing `.`. In particular, the global variables created to represent the runtime information of derived types use `.` in their names. A derived type's descriptor object may be used in the device code, e.g. to initialize a descriptor of a variable of this type. Thus, the runtime type info objects may need to be compiled for the device. Moreover, at least the derived types' descriptor objects may need to be registered (think of `omp declare target`) for the host-device association so that the addendum pointer can be properly mapped to the device for descriptors using a derived type's descriptor as their addendum pointer. The registration implies knowing the name of the global variable in the device image so that proper host code can be created. So it is better to name the globals the same way for the host and the device. CompilerGeneratedNamesConversion pass renames all uniqued globals such that the special symbols (currently `.`) are replaced with `X`. The pass is supposed to be run for the host and the device. An option is added to FIR-to-LLVM conversion pass to indicate whether the new pass has been run before or not. This setting affects how the codegen computes the names of the derived types' descriptors for FIR derived types. fir::NameUniquer now allows `X` to be part of a name, because the name deconstruction may be applied to the mangled names after CompilerGeneratedNamesConversion pass.
2024-08-21 13:37:03 -07:00
if (typeDescriptorsRenamedForAssembly)
options.typeDescriptorsRenamedForAssembly =
typeDescriptorsRenamedForAssembly;
[flang] Lower integer exponentiation into math::IPowI. Differential Revision: https://reviews.llvm.org/D132770
2022-08-26 16:12:25 -07:00
// Run dynamic pass pipeline for converting Math dialect
// operations into other dialects (llvm, func, etc.).
// Some conversions of Math operations cannot be done
// by just using conversion patterns. This is true for
// conversions that affect the ModuleOp, e.g. create new
// function operations in it. We have to run such conversions
// as passes here.
mlir::OpPassManager mathConvertionPM("builtin.module");
[flang] Lower exponentiation without using pgmath. Exponentiation is lowered to either math::FPowI or Fortran runtime call (in case of --math-runtime=precise). MathToFuncs convertor will convert math::FPowI operations with exponent width >32 to calls of outlined implementations and otherwise will leave the operation to MathToLLVM convertor. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D139806
2022-12-14 10:22:00 -08:00
[flang][AMDGPU] Convert math ops to AMD GPU library calls instead of libm calls (#99517) This patch invokes a pass when compiling for an AMDGPU target to lower math operations to AMD GPU library calls library calls instead of libm calls.
2024-09-10 09:48:55 -04:00
bool isAMDGCN = fir::getTargetTriple(mod).isAMDGCN();
// If compiling for AMD target some math operations must be lowered to AMD
// GPU library calls, the rest can be converted to LLVM intrinsics, which
// is handled in the mathToLLVM conversion. The lowering to libm calls is
// not needed since all math operations are handled this way.
if (isAMDGCN)
mathConvertionPM.addPass(mlir::createConvertMathToROCDL());
[flang] Lower exponentiation without using pgmath. Exponentiation is lowered to either math::FPowI or Fortran runtime call (in case of --math-runtime=precise). MathToFuncs convertor will convert math::FPowI operations with exponent width >32 to calls of outlined implementations and otherwise will leave the operation to MathToLLVM convertor. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D139806
2022-12-14 10:22:00 -08:00
// Convert math::FPowI operations to inline implementation
// only if the exponent's width is greater than 32, otherwise,
// it will be lowered to LLVM intrinsic operation by a later conversion.
mlir::ConvertMathToFuncsOptions mathToFuncsOptions{};
mathToFuncsOptions.minWidthOfFPowIExponent = 33;
mathConvertionPM.addPass(
mlir::createConvertMathToFuncs(mathToFuncsOptions));
[flang] Use mlir complex dialect for supported operations This patch lowers the complex operations supported by the MLIR complex dialect to those operations rather than libm. When the math runtime flag is set to precise, libm lowering is used instead. Differential Revision: https://reviews.llvm.org/D135882
2022-10-24 12:42:29 +00:00
mathConvertionPM.addPass(mlir::createConvertComplexToStandardPass());
[flang] Run MathToLLVM conversion as part of math conversion PM. We used to specify benefit=0 for MathToLibm patterns so that MathToLLVM patterns are more preferable. D144450 removed the benefit parameter, so we have to run MathToLLVM separately now. This resolves Intrinsics/math-codegen failure caused by D144450. Differential Revision: https://reviews.llvm.org/D144523
2023-02-21 14:55:00 -08:00
// Convert Math dialect operations into LLVM dialect operations.
// There is no way to prefer MathToLLVM patterns over MathToLibm
// patterns (applied below), so we have to run MathToLLVM conversion here.
mathConvertionPM.addNestedPass<mlir::func::FuncOp>(
mlir::createConvertMathToLLVMPass());
[flang] Lower integer exponentiation into math::IPowI. Differential Revision: https://reviews.llvm.org/D132770
2022-08-26 16:12:25 -07:00
if (mlir::failed(runPipeline(mathConvertionPM, mod)))
return signalPassFailure();
[flang] Add struct passing target rewrite hooks and partial X86-64 impl (#74829) In the context of C/Fortran interoperability (BIND(C)), it is possible to give the VALUE attribute to a BIND(C) derived type dummy, which according to Fortran 2018 18.3.6 - 2. (4) implies that it must be passed like the equivalent C structure value. The way C structure value are passed is ABI dependent. LLVM does not implement the C struct ABI passing for LLVM aggregate type arguments. It is up to the front-end, like clang is doing, to split the struct into registers or pass the struct on the stack (llvm "byval") as required by the target ABI. So the logic for C struct passing sits in clang. Using it from flang requires setting up a lot of clang context and to bridge FIR/MLIR representation to clang AST representation for function signatures (in both directions). It is a non trivial task. See https://stackoverflow.com/questions/39438033/passing-structs-by-value-in-llvm-ir/75002581#75002581. Since BIND(C) struct are rather limited as opposed to generic C struct (e.g. no bit fields). It is easier to provide a limited implementation of it for the case that matter to Fortran. This patch: - Updates the generic target rewrite pass to keep track of both the new argument type and attributes. The motivation for this is to be able to tell if a previously marshalled argument is passed in memory (it is a C pointer), or if it is being passed on the stack (has the byval llvm attributes). - Adds an entry point in the target specific codegen to marshal struct arguments, and use it in the generic target rewrite pass. - Implements limited support for the X86-64 case. So far, the support allows telling if a struct must be passed in register or on the stack, and to deal with the stack case. The register case is left TODO in this patch. The X86-64 ABI implemented is the System V ABI for AMD64 version 1.0
2023-12-12 11:52:39 +01:00
std::optional<mlir::DataLayout> dl =
[Flang][MLIR] Extend DataLayout utilities to have basic GPU Module support (#123149) As there is now certain areas where we now have the possibility of having either a ModuleOp or GPUModuleOp and both of these modules can have DataLayout's and we may require utilising the DataLayout utilities in these areas I've taken the liberty of trying to extend them for use with both. Those with more knowledge of how they wish the GPUModuleOp's to interact with their parent ModuleOp's DataLayout may have further alterations they wish to make in the future, but for the moment, it'll simply utilise the basic data layout construction which I believe combines parent and child datalayouts from the ModuleOp and GPUModuleOp. If there is no GPUModuleOp DataLayout it should default to the parent ModuleOp. It's worth noting there is some weirdness if you have two module operations defining builtin dialect DataLayout Entries, it appears the combinatorial functionality for DataLayouts doesn't support the merging of these. This behaviour is useful for areas like: https://github.com/llvm/llvm-project/pull/119585/files#diff-19fc4bcb38829d085e25d601d344bbd85bf7ef749ca359e348f4a7c750eae89dR1412 where we have a crossroads between the two different module operations.
2025-01-30 17:31:50 +01:00
fir::support::getOrSetMLIRDataLayout(mod, /*allowDefaultLayout=*/true);
[flang] Add struct passing target rewrite hooks and partial X86-64 impl (#74829) In the context of C/Fortran interoperability (BIND(C)), it is possible to give the VALUE attribute to a BIND(C) derived type dummy, which according to Fortran 2018 18.3.6 - 2. (4) implies that it must be passed like the equivalent C structure value. The way C structure value are passed is ABI dependent. LLVM does not implement the C struct ABI passing for LLVM aggregate type arguments. It is up to the front-end, like clang is doing, to split the struct into registers or pass the struct on the stack (llvm "byval") as required by the target ABI. So the logic for C struct passing sits in clang. Using it from flang requires setting up a lot of clang context and to bridge FIR/MLIR representation to clang AST representation for function signatures (in both directions). It is a non trivial task. See https://stackoverflow.com/questions/39438033/passing-structs-by-value-in-llvm-ir/75002581#75002581. Since BIND(C) struct are rather limited as opposed to generic C struct (e.g. no bit fields). It is easier to provide a limited implementation of it for the case that matter to Fortran. This patch: - Updates the generic target rewrite pass to keep track of both the new argument type and attributes. The motivation for this is to be able to tell if a previously marshalled argument is passed in memory (it is a C pointer), or if it is being passed on the stack (has the byval llvm attributes). - Adds an entry point in the target specific codegen to marshal struct arguments, and use it in the generic target rewrite pass. - Implements limited support for the X86-64 case. So far, the support allows telling if a struct must be passed in register or on the stack, and to deal with the stack case. The register case is left TODO in this patch. The X86-64 ABI implemented is the System V ABI for AMD64 version 1.0
2023-12-12 11:52:39 +01:00
if (!dl) {
mlir::emitError(mod.getLoc(),
"module operation must carry a data layout attribute "
"to generate llvm IR from FIR");
signalPassFailure();
return;
}
[fir] Add base of the FIR to LLVM IR pass This patch adds the base of the FIR to LLVM IR Dialect conversion pass. It currently can convert the following operations: - fir.global - fir.has_value - fir.address_of - fir.undefined This patch is part of the upstreaming effort from fir-dev branch. It does not cover all FIR operations in order to have small patches. Several patches will follow to convert other operations. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D112845
2021-10-29 23:20:50 +02:00
auto *context = getModule().getContext();
[flang] Generate TBAA information. This is initial version of TBAA information generation for Flang generated IR. The desired behavior is that TBAA type descriptors are generated for FIR types during FIR to LLVM types conversion, and then TBAA access tags are attached to memory accessing operations when they are converted to LLVM IR dialect. In the initial version the type conversion is not producing TBAA type descriptors, and all memory accesses are just partitioned into two sets of box and non-box accesses, which can never alias. The TBAA generation is enabled by default at >O0 optimization levels. TBAA generation may also be enabled via `apply-tbaa` option of `fir-to-llvm-ir` conversion pass. `-mllvm -disable-tbaa` engineering option allows disabling TBAA generation to override Flang's default (e.g. when -O1 is used). SPEC CPU2006/437.leslie3d speeds up by more than 2x on Icelake. Reviewed By: jeanPerier, clementval Differential Revision: https://reviews.llvm.org/D141820
2023-01-17 09:08:43 -08:00
fir::LLVMTypeConverter typeConverter{getModule(),
[flang][driver] add command line arguments for alias tags pass The ultimate intention is to have this pass enabled by default whenever we are optimizing for speed. But for now, just add the arguments so this can be more easily tested. PR: https://github.com/llvm/llvm-project/pull/68595
2023-09-14 09:09:29 +00:00
options.applyTBAA || applyTBAA,
[flang] Add struct passing target rewrite hooks and partial X86-64 impl (#74829) In the context of C/Fortran interoperability (BIND(C)), it is possible to give the VALUE attribute to a BIND(C) derived type dummy, which according to Fortran 2018 18.3.6 - 2. (4) implies that it must be passed like the equivalent C structure value. The way C structure value are passed is ABI dependent. LLVM does not implement the C struct ABI passing for LLVM aggregate type arguments. It is up to the front-end, like clang is doing, to split the struct into registers or pass the struct on the stack (llvm "byval") as required by the target ABI. So the logic for C struct passing sits in clang. Using it from flang requires setting up a lot of clang context and to bridge FIR/MLIR representation to clang AST representation for function signatures (in both directions). It is a non trivial task. See https://stackoverflow.com/questions/39438033/passing-structs-by-value-in-llvm-ir/75002581#75002581. Since BIND(C) struct are rather limited as opposed to generic C struct (e.g. no bit fields). It is easier to provide a limited implementation of it for the case that matter to Fortran. This patch: - Updates the generic target rewrite pass to keep track of both the new argument type and attributes. The motivation for this is to be able to tell if a previously marshalled argument is passed in memory (it is a C pointer), or if it is being passed on the stack (has the byval llvm attributes). - Adds an entry point in the target specific codegen to marshal struct arguments, and use it in the generic target rewrite pass. - Implements limited support for the X86-64 case. So far, the support allows telling if a struct must be passed in register or on the stack, and to deal with the stack case. The register case is left TODO in this patch. The X86-64 ABI implemented is the System V ABI for AMD64 version 1.0
2023-12-12 11:52:39 +01:00
options.forceUnifiedTBAATree, *dl};
[mlir] Finish replacing OwningRewritePatternList with RewritePatternSet OwningRewritePatternList has been deprecated for ~10 months now, we can remove the leftover using directives at this point. Differential Revision: https://reviews.llvm.org/D118287
2022-01-26 14:42:38 -08:00
mlir::RewritePatternSet pattern(context);
[flang][NFC] Expose FIR to LLVM patterns (#83492) The FIR dialect has been initiated before many interfaces have been introduced to MLIR. This patch expose the FIR to LLVM patterns in a `populateFIRToLLVMConversionPatterns` function. The idea is to be able to add the `ConvertToLLVMPatternInterface`. This is not directly possible since the FIR dialect does not currently use the table infrastructure for its definition. Follow up patches will move the FIR dialect definition to table gen and then implement the interface.
2024-03-04 00:11:59 -08:00
fir::populateFIRToLLVMConversionPatterns(typeConverter, pattern, options);
[mlir][NFC] Rename StandardToLLVM to FuncToLLVM The current StandardToLLVM conversion patterns only really handle the Func dialect. The pass itself adds patterns for Arithmetic/CFToLLVM, but those should be/will be split out in a followup. This commit focuses solely on being an NFC rename. Aside from the directory change, the pattern and pass creation API have been renamed: * populateStdToLLVMFuncOpConversionPattern -> populateFuncToLLVMFuncOpConversionPattern * populateStdToLLVMConversionPatterns -> populateFuncToLLVMConversionPatterns * createLowerToLLVMPass -> createConvertFuncToLLVMPass Differential Revision: https://reviews.llvm.org/D120778
2022-03-01 14:53:41 -08:00
mlir::populateFuncToLLVMConversionPatterns(typeConverter, pattern);
[Flang] Add OpenMP Conversion patterns This patch adds the OpenMP conversion patterns to the FIR to LLVM dialect lowering pass in Codegen. Appropriate legalization conditions are also added. This ensures that a mix of FIR and OpenMP dialects can be lowered to LLVM and OpenMP dialects. Also adds two tests. This is part of the upstreaming effort from the fir-dev branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Reviewed By: clementval, peixin Differential Revision: https://reviews.llvm.org/D121793 Co-authored-by: Sourabh Singh Tomar <SourabhSingh.Tomar@amd.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2022-03-21 14:09:47 +00:00
mlir::populateOpenMPToLLVMConversionPatterns(typeConverter, pattern);
[flang][mlir][arith] Fix flang build after dialect renaming Tested with `ninja check-flang`
2022-09-29 11:55:17 -04:00
mlir::arith::populateArithToLLVMConversionPatterns(typeConverter, pattern);
[mlir] Split out a new ControlFlow dialect from Standard This dialect is intended to model lower level/branch based control-flow constructs. The initial set of operations are: AssertOp, BranchOp, CondBranchOp, SwitchOp; all split out from the current standard dialect. See https://discourse.llvm.org/t/standard-dialect-the-final-chapter/6061 Differential Revision: https://reviews.llvm.org/D118966
2022-02-03 20:59:43 -08:00
mlir::cf::populateControlFlowToLLVMConversionPatterns(typeConverter,
pattern);
[mlir][GPU] Add NVVM-specific `cf.assert` lowering (#120431) This commit add an NVIDIA-specific lowering of `cf.assert` to to `__assertfail`. Note: `getUniqueFormatGlobalName`, `getOrCreateFormatStringConstant` and `getOrDefineFunction` are moved to `GPUOpsLowering.h`, so that they can be reused.
2025-01-06 12:00:11 +01:00
mlir::cf::populateAssertToLLVMConversionPattern(typeConverter, pattern);
[flang] Run MathToLLVM conversion as part of math conversion PM. We used to specify benefit=0 for MathToLibm patterns so that MathToLLVM patterns are more preferable. D144450 removed the benefit parameter, so we have to run MathToLLVM separately now. This resolves Intrinsics/math-codegen failure caused by D144450. Differential Revision: https://reviews.llvm.org/D144523
2023-02-21 14:55:00 -08:00
// Math operations that have not been converted yet must be converted
// to Libm.
[flang][AMDGPU] Convert math ops to AMD GPU library calls instead of libm calls (#99517) This patch invokes a pass when compiling for an AMDGPU target to lower math operations to AMD GPU library calls library calls instead of libm calls.
2024-09-10 09:48:55 -04:00
if (!isAMDGCN)
mlir::populateMathToLibmConversionPatterns(pattern);
[flang] Use mlir complex dialect for supported operations This patch lowers the complex operations supported by the MLIR complex dialect to those operations rather than libm. When the math runtime flag is set to precise, libm lowering is used instead. Differential Revision: https://reviews.llvm.org/D135882
2022-10-24 12:42:29 +00:00
mlir::populateComplexToLLVMConversionPatterns(typeConverter, pattern);
[flang] Add PowerPC vec_add, vec_and, vec_mul, vec_sub and vec_xor intrinsics Differential Revision: https://reviews.llvm.org/D151857
2023-05-29 16:10:12 -04:00
mlir::populateVectorToLLVMConversionPatterns(typeConverter, pattern);
[Flang][OpenMP] Initial mapping of Fortran pointers and allocatables for target devices (#71766) This patch seeks to add an initial lowering for pointers and allocatable variables captured by implicit and explicit map in Flang OpenMP for Target operations that take map clauses e.g. Target, Target Update. Target Exit/Enter etc. Currently this is done by treating the type that lowers to a descriptor (allocatable/pointer/assumed shape) as a map of a record type (e.g. a structure) as that's effectively what descriptor types lower to in LLVM-IR and what they're represented as in the Fortran runtime (written in C/C++). The descriptor effectively lowers to a structure containing scalar and array elements that represent various aspects of the underlying data being mapped (lower bound, upper bound, extent being the main ones of interest in most cases) and a pointer to the allocated data. In this current iteration of the mapping we map the structure in it's entirety and then attach the underlying data pointer and map the data to the device, this allows most of the required data to be resident on the device for use. Currently we do not support the addendum (another block of pointer data), but it shouldn't be too difficult to extend this to support it. The MapInfoOp generation for descriptor types is primarily handled in an optimization pass, where it expands BoxType (descriptor types) map captures into two maps, one for the structure (scalar elements) and the other for the pointer data (base address) and links them in a Parent <-> Child relationship. The later lowering processes will then treat them as a conjoined structure with a pointer member map.
2024-02-05 18:45:07 +01:00
// Flang specific overloads for OpenMP operations, to allow for special
// handling of things like Box types.
fir::populateOpenMPFIRToLLVMConversionPatterns(typeConverter, pattern);
[fir] Add base of the FIR to LLVM IR pass This patch adds the base of the FIR to LLVM IR Dialect conversion pass. It currently can convert the following operations: - fir.global - fir.has_value - fir.address_of - fir.undefined This patch is part of the upstreaming effort from fir-dev branch. It does not cover all FIR operations in order to have small patches. Several patches will follow to convert other operations. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D112845
2021-10-29 23:20:50 +02:00
mlir::ConversionTarget target{*context};
target.addLegalDialect<mlir::LLVM::LLVMDialect>();
[Flang] Add OpenMP Conversion patterns This patch adds the OpenMP conversion patterns to the FIR to LLVM dialect lowering pass in Codegen. Appropriate legalization conditions are also added. This ensures that a mix of FIR and OpenMP dialects can be lowered to LLVM and OpenMP dialects. Also adds two tests. This is part of the upstreaming effort from the fir-dev branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Reviewed By: clementval, peixin Differential Revision: https://reviews.llvm.org/D121793 Co-authored-by: Sourabh Singh Tomar <SourabhSingh.Tomar@amd.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2022-03-21 14:09:47 +00:00
// The OpenMP dialect is legal for Operations without regions, for those
// which contains regions it is legal if the region contains only the
Added lowering support for atomic read and write constructs This patch adds lowering support for atomic read and write constructs. Also added is pointer modelling code to allow FIR pointer like types to be inferred and converted while lowering. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D122725 Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>
2022-04-21 09:15:45 +05:30
// LLVM dialect. Add OpenMP dialect as a legal dialect for conversion and
// legalize conversion of OpenMP operations without regions.
mlir::configureOpenMPToLLVMConversionLegality(target, typeConverter);
[Flang] Add OpenMP Conversion patterns This patch adds the OpenMP conversion patterns to the FIR to LLVM dialect lowering pass in Codegen. Appropriate legalization conditions are also added. This ensures that a mix of FIR and OpenMP dialects can be lowered to LLVM and OpenMP dialects. Also adds two tests. This is part of the upstreaming effort from the fir-dev branch in [1]. [1] https://github.com/flang-compiler/f18-llvm-project Reviewed By: clementval, peixin Differential Revision: https://reviews.llvm.org/D121793 Co-authored-by: Sourabh Singh Tomar <SourabhSingh.Tomar@amd.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2022-03-21 14:09:47 +00:00
target.addLegalDialect<mlir::omp::OpenMPDialect>();
[flang][openacc] Add missing piece to translate to LLVM IR dialect Add missing pieces to translate handle OpenACC dialect in the translation. Depends on D147825 Reviewed By: PeteSteinfeld, razvanlupusoru Differential Revision: https://reviews.llvm.org/D147828
2023-04-10 14:29:58 -07:00
target.addLegalDialect<mlir::acc::OpenACCDialect>();
[flang][cuda] Support malloc and free conversion in gpu module (#116112)
2024-11-13 17:09:38 -08:00
target.addLegalDialect<mlir::gpu::GPUDialect>();
[fir] Add base of the FIR to LLVM IR pass This patch adds the base of the FIR to LLVM IR Dialect conversion pass. It currently can convert the following operations: - fir.global - fir.has_value - fir.address_of - fir.undefined This patch is part of the upstreaming effort from fir-dev branch. It does not cover all FIR operations in order to have small patches. Several patches will follow to convert other operations. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D112845
2021-10-29 23:20:50 +02:00
// required NOPs for applying a full conversion
target.addLegalOp<mlir::ModuleOp>();
[flang] Rename hypotf on MSVC platforms The single precision `hypot` intrinsic is lowered to a call to the libm `hypotf` function. However, the MSVC runtime lacks a hypotf function and instead uses `_hypotf` (*). This patch tries to find and rewrite calls to `hypotf` if we're on a MSVC platform. Calls to libm functions can be introduced even after lowering (**). Therefore, we try to do the rewriting at the very end of FIR to LLVM lowering. Fixes https://github.com/llvm/llvm-project/issues/57563 (*) More specifically, MSVC's headers define hypotf as an inline function that just calls _hypotf. This works fine for clang, since it will include those headers, but flang only links with the CRT so we don't get a free ride. (**) https://github.com/llvm/llvm-project/blob/56f94ede2af9a327e59fe84dbf8cbbb7bb1dfa79/flang/lib/Optimizer/CodeGen/CodeGen.cpp#L3391 Differential Revision: https://reviews.llvm.org/D135853
2022-10-11 12:38:08 +00:00
// If we're on Windows, we might need to rename some libm calls.
bool isMSVC = fir::getTargetTriple(mod).isOSMSVCRT();
if (isMSVC) {
pattern.insert<RenameMSVCLibmCallees, RenameMSVCLibmFuncs>(context);
target.addDynamicallyLegalOp<mlir::LLVM::CallOp>(
[](mlir::LLVM::CallOp op) {
auto callee = op.getCallee();
if (!callee)
return true;
Use StringRef::operator== instead of StringRef::equals (NFC) (#91864) I'm planning to remove StringRef::equals in favor of StringRef::operator==. - StringRef::operator==/!= outnumber StringRef::equals by a factor of 276 under llvm-project/ in terms of their usage. - The elimination of StringRef::equals brings StringRef closer to std::string_view, which has operator== but not equals. - S == "foo" is more readable than S.equals("foo"), especially for !Long.Expression.equals("str") vs Long.Expression != "str".
2024-05-12 23:08:40 -07:00
return *callee != "hypotf";
[flang] Rename hypotf on MSVC platforms The single precision `hypot` intrinsic is lowered to a call to the libm `hypotf` function. However, the MSVC runtime lacks a hypotf function and instead uses `_hypotf` (*). This patch tries to find and rewrite calls to `hypotf` if we're on a MSVC platform. Calls to libm functions can be introduced even after lowering (**). Therefore, we try to do the rewriting at the very end of FIR to LLVM lowering. Fixes https://github.com/llvm/llvm-project/issues/57563 (*) More specifically, MSVC's headers define hypotf as an inline function that just calls _hypotf. This works fine for clang, since it will include those headers, but flang only links with the CRT so we don't get a free ride. (**) https://github.com/llvm/llvm-project/blob/56f94ede2af9a327e59fe84dbf8cbbb7bb1dfa79/flang/lib/Optimizer/CodeGen/CodeGen.cpp#L3391 Differential Revision: https://reviews.llvm.org/D135853
2022-10-11 12:38:08 +00:00
});
target.addDynamicallyLegalOp<mlir::LLVM::LLVMFuncOp>(
[](mlir::LLVM::LLVMFuncOp op) {
Use StringRef::operator== instead of StringRef::equals (NFC) (#91864) I'm planning to remove StringRef::equals in favor of StringRef::operator==. - StringRef::operator==/!= outnumber StringRef::equals by a factor of 276 under llvm-project/ in terms of their usage. - The elimination of StringRef::equals brings StringRef closer to std::string_view, which has operator== but not equals. - S == "foo" is more readable than S.equals("foo"), especially for !Long.Expression.equals("str") vs Long.Expression != "str".
2024-05-12 23:08:40 -07:00
return op.getSymName() != "hypotf";
[flang] Rename hypotf on MSVC platforms The single precision `hypot` intrinsic is lowered to a call to the libm `hypotf` function. However, the MSVC runtime lacks a hypotf function and instead uses `_hypotf` (*). This patch tries to find and rewrite calls to `hypotf` if we're on a MSVC platform. Calls to libm functions can be introduced even after lowering (**). Therefore, we try to do the rewriting at the very end of FIR to LLVM lowering. Fixes https://github.com/llvm/llvm-project/issues/57563 (*) More specifically, MSVC's headers define hypotf as an inline function that just calls _hypotf. This works fine for clang, since it will include those headers, but flang only links with the CRT so we don't get a free ride. (**) https://github.com/llvm/llvm-project/blob/56f94ede2af9a327e59fe84dbf8cbbb7bb1dfa79/flang/lib/Optimizer/CodeGen/CodeGen.cpp#L3391 Differential Revision: https://reviews.llvm.org/D135853
2022-10-11 12:38:08 +00:00
});
}
[fir] Add base of the FIR to LLVM IR pass This patch adds the base of the FIR to LLVM IR Dialect conversion pass. It currently can convert the following operations: - fir.global - fir.has_value - fir.address_of - fir.undefined This patch is part of the upstreaming effort from fir-dev branch. It does not cover all FIR operations in order to have small patches. Several patches will follow to convert other operations. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D112845
2021-10-29 23:20:50 +02:00
// apply the patterns
if (mlir::failed(mlir::applyFullConversion(getModule(), target,
std::move(pattern)))) {
signalPassFailure();
}
[flang] Add comdats to functions with linkonce linkage (#66516) This fixes a bug where functions generated by the MLIR Math dialect, for example ipowi, would fail to link with link.exe on Windows due to having linkonce linkage but no associated comdat. Adding the comdat on ELF also allows linkers to perform better garbage collection in the binary. Simply adding comdats to all functions with this linkage type should also cover future cases where linkonce or linkonce_odr functions might be necessary.
2023-09-19 15:00:04 +01:00
[flang] Remove materialization workaround in type converter (#98743) This change is in preparation of #97903, which adds extra checks for materializations: it is now enforced that they produce an SSA value of the correct type, so the current workaround no longer works. The original workaround avoided target materializations by directly returning the to-be-converted SSA value from the materialization callback. This can be avoided by initializing the lowering patterns that insert the materializations without a type converter. For `cg::XEmboxOp`, the existing workaround that skips `unrealized_conversion_cast` ops is still in place. Also remove the lowering pattern for `unrealized_conversion_cast`. This pattern has no effect because `unrealized_conversion_cast` ops that are inserted by the dialect conversion framework are never matched by the pattern driver.
2024-07-15 16:07:48 +02:00
// Run pass to add comdats to functions that have weak linkage on relevant
// platforms
[flang] Add comdats to functions with linkonce linkage (#66516) This fixes a bug where functions generated by the MLIR Math dialect, for example ipowi, would fail to link with link.exe on Windows due to having linkonce linkage but no associated comdat. Adding the comdat on ELF also allows linkers to perform better garbage collection in the binary. Simply adding comdats to all functions with this linkage type should also cover future cases where linkonce or linkonce_odr functions might be necessary.
2023-09-19 15:00:04 +01:00
if (fir::getTargetTriple(mod).supportsCOMDAT()) {
mlir::OpPassManager comdatPM("builtin.module");
comdatPM.addPass(mlir::LLVM::createLLVMAddComdats());
if (mlir::failed(runPipeline(comdatPM, mod)))
return signalPassFailure();
}
[fir] Add base of the FIR to LLVM IR pass This patch adds the base of the FIR to LLVM IR Dialect conversion pass. It currently can convert the following operations: - fir.global - fir.has_value - fir.address_of - fir.undefined This patch is part of the upstreaming effort from fir-dev branch. It does not cover all FIR operations in order to have small patches. Several patches will follow to convert other operations. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D112845
2021-10-29 23:20:50 +02:00
}
[flang] Support PDT type descriptors in codegen This change updates the mapping of derived types and type descriptor object names to support kind parametrized derived types (PDT). It moves the custom name mapping to the internal name utility. To improve robustness and error reporting, type descriptors are also now required to be generated in all compilation unit that manipulates derived types. The previous codegen relied on the fact that descriptors not defined in the current FIR module were available externally. Errors with missing type descriptors were only caught at link time. This patch makes derived type definition mandatory, except if the derived types are expected to not have derived type descriptors (builtin types), or if the newly added debug switch `--ignore-missing-type-desc` is set. In those cases, a null pointer is used as type descriptor pointer. The debug switch intends to help testing FIR to LLVM passes without having to bother providing type descriptor data structures that are normally built by the front-end. Differential Revision: https://reviews.llvm.org/D120804
2022-03-03 10:07:34 +01:00
private:
fir::FIRToLLVMPassOptions options;
[fir] Add base of the FIR to LLVM IR pass This patch adds the base of the FIR to LLVM IR Dialect conversion pass. It currently can convert the following operations: - fir.global - fir.has_value - fir.address_of - fir.undefined This patch is part of the upstreaming effort from fir-dev branch. It does not cover all FIR operations in order to have small patches. Several patches will follow to convert other operations. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D112845
2021-10-29 23:20:50 +02:00
};
[flang] Update tco tool pipline and add translation to LLVM IR tco is a tool to test the FIR to LLVM IR pipeline of the Flang compiler. This patch update tco pipelines and adds the translation to LLVM IR. A simple test is added to make sure the tool is working with a simple FIR program. More tests will be upstream in follow up patch from the fir-dev branch. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski, schweitz, mehdi_amini Differential Revision: https://reviews.llvm.org/D117781 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
2022-01-24 14:14:49 +01:00
/// Lower from LLVM IR dialect to proper LLVM-IR and dump the module
struct LLVMIRLoweringPass
: public mlir::PassWrapper<LLVMIRLoweringPass,
mlir::OperationPass<mlir::ModuleOp>> {
[mlir] Rework the implementation of TypeID This commit restructures how TypeID is implemented to ideally avoid the current problems related to shared libraries. This is done by changing the "implicit" fallback path to use the name of the type, instead of using a static template variable (which breaks shared libraries). The major downside to this is that it adds some additional initialization costs for the implicit path. Given the use of type names for uniqueness in the fallback, we also no longer allow types defined in anonymous namespaces to have an implicit TypeID. To simplify defining an ID for these classes, a new `MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID` macro was added to allow for explicitly defining a TypeID directly on an internal class. To help identify when types are using the fallback, `-debug-only=typeid` can be used to log which types are using implicit ids. This change generally only requires changes to the test passes, which are all defined in anonymous namespaces, and thus can't use the fallback any longer. Differential Revision: https://reviews.llvm.org/D122775
2022-03-30 17:00:37 -07:00
MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID(LLVMIRLoweringPass)
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
LLVMIRLoweringPass(llvm::raw_ostream &output, fir::LLVMIRLoweringPrinter p)
[flang] Update tco tool pipline and add translation to LLVM IR tco is a tool to test the FIR to LLVM IR pipeline of the Flang compiler. This patch update tco pipelines and adds the translation to LLVM IR. A simple test is added to make sure the tool is working with a simple FIR program. More tests will be upstream in follow up patch from the fir-dev branch. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski, schweitz, mehdi_amini Differential Revision: https://reviews.llvm.org/D117781 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
2022-01-24 14:14:49 +01:00
: output{output}, printer{p} {}
mlir::ModuleOp getModule() { return getOperation(); }
void runOnOperation() override final {
auto *ctx = getModule().getContext();
auto optName = getModule().getName();
llvm::LLVMContext llvmCtx;
if (auto llvmModule = mlir::translateModuleToLLVMIR(
getModule(), llvmCtx, optName ? *optName : "FIRModule")) {
printer(*llvmModule, output);
return;
}
mlir::emitError(mlir::UnknownLoc::get(ctx), "could not emit LLVM-IR\n");
signalPassFailure();
}
private:
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
llvm::raw_ostream &output;
fir::LLVMIRLoweringPrinter printer;
[flang] Update tco tool pipline and add translation to LLVM IR tco is a tool to test the FIR to LLVM IR pipeline of the Flang compiler. This patch update tco pipelines and adds the translation to LLVM IR. A simple test is added to make sure the tool is working with a simple FIR program. More tests will be upstream in follow up patch from the fir-dev branch. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski, schweitz, mehdi_amini Differential Revision: https://reviews.llvm.org/D117781 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
2022-01-24 14:14:49 +01:00
};
[fir] Add base of the FIR to LLVM IR pass This patch adds the base of the FIR to LLVM IR Dialect conversion pass. It currently can convert the following operations: - fir.global - fir.has_value - fir.address_of - fir.undefined This patch is part of the upstreaming effort from fir-dev branch. It does not cover all FIR operations in order to have small patches. Several patches will follow to convert other operations. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D112845
2021-10-29 23:20:50 +02:00
} // namespace
std::unique_ptr<mlir::Pass> fir::createFIRToLLVMPass() {
return std::make_unique<FIRToLLVMLowering>();
}
[flang] Update tco tool pipline and add translation to LLVM IR tco is a tool to test the FIR to LLVM IR pipeline of the Flang compiler. This patch update tco pipelines and adds the translation to LLVM IR. A simple test is added to make sure the tool is working with a simple FIR program. More tests will be upstream in follow up patch from the fir-dev branch. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski, schweitz, mehdi_amini Differential Revision: https://reviews.llvm.org/D117781 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
2022-01-24 14:14:49 +01:00
[flang] Support PDT type descriptors in codegen This change updates the mapping of derived types and type descriptor object names to support kind parametrized derived types (PDT). It moves the custom name mapping to the internal name utility. To improve robustness and error reporting, type descriptors are also now required to be generated in all compilation unit that manipulates derived types. The previous codegen relied on the fact that descriptors not defined in the current FIR module were available externally. Errors with missing type descriptors were only caught at link time. This patch makes derived type definition mandatory, except if the derived types are expected to not have derived type descriptors (builtin types), or if the newly added debug switch `--ignore-missing-type-desc` is set. In those cases, a null pointer is used as type descriptor pointer. The debug switch intends to help testing FIR to LLVM passes without having to bother providing type descriptor data structures that are normally built by the front-end. Differential Revision: https://reviews.llvm.org/D120804
2022-03-03 10:07:34 +01:00
std::unique_ptr<mlir::Pass>
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
fir::createFIRToLLVMPass(fir::FIRToLLVMPassOptions options) {
[flang] Support PDT type descriptors in codegen This change updates the mapping of derived types and type descriptor object names to support kind parametrized derived types (PDT). It moves the custom name mapping to the internal name utility. To improve robustness and error reporting, type descriptors are also now required to be generated in all compilation unit that manipulates derived types. The previous codegen relied on the fact that descriptors not defined in the current FIR module were available externally. Errors with missing type descriptors were only caught at link time. This patch makes derived type definition mandatory, except if the derived types are expected to not have derived type descriptors (builtin types), or if the newly added debug switch `--ignore-missing-type-desc` is set. In those cases, a null pointer is used as type descriptor pointer. The debug switch intends to help testing FIR to LLVM passes without having to bother providing type descriptor data structures that are normally built by the front-end. Differential Revision: https://reviews.llvm.org/D120804
2022-03-03 10:07:34 +01:00
return std::make_unique<FIRToLLVMLowering>(options);
}
[flang] Update tco tool pipline and add translation to LLVM IR tco is a tool to test the FIR to LLVM IR pipeline of the Flang compiler. This patch update tco pipelines and adds the translation to LLVM IR. A simple test is added to make sure the tool is working with a simple FIR program. More tests will be upstream in follow up patch from the fir-dev branch. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski, schweitz, mehdi_amini Differential Revision: https://reviews.llvm.org/D117781 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
2022-01-24 14:14:49 +01:00
std::unique_ptr<mlir::Pass>
[NFC] More synching of sources for upstreaming. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D124476
2022-04-26 13:44:34 -07:00
fir::createLLVMDialectToLLVMPass(llvm::raw_ostream &output,
[flang] Update tco tool pipline and add translation to LLVM IR tco is a tool to test the FIR to LLVM IR pipeline of the Flang compiler. This patch update tco pipelines and adds the translation to LLVM IR. A simple test is added to make sure the tool is working with a simple FIR program. More tests will be upstream in follow up patch from the fir-dev branch. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan, awarzynski, schweitz, mehdi_amini Differential Revision: https://reviews.llvm.org/D117781 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
2022-01-24 14:14:49 +01:00
fir::LLVMIRLoweringPrinter printer) {
return std::make_unique<LLVMIRLoweringPass>(output, printer);
}
[flang][NFC] Expose FIR to LLVM patterns (#83492) The FIR dialect has been initiated before many interfaces have been introduced to MLIR. This patch expose the FIR to LLVM patterns in a `populateFIRToLLVMConversionPatterns` function. The idea is to be able to add the `ConvertToLLVMPatternInterface`. This is not directly possible since the FIR dialect does not currently use the table infrastructure for its definition. Follow up patches will move the FIR dialect definition to table gen and then implement the interface.
2024-03-04 00:11:59 -08:00
void fir::populateFIRToLLVMConversionPatterns(
[mlir][NFC] Mark type converter in `populate...` functions as `const` (#111250) This commit marks the type converter in `populate...` functions as `const`. This is useful for debugging. Patterns already take a `const` type converter. However, some `populate...` functions do not only add new patterns, but also add additional type conversion rules. That makes it difficult to find the place where a type conversion was added in the code base. With this change, all `populate...` functions that only populate pattern now have a `const` type converter. Programmers can then conclude from the function signature that these functions do not register any new type conversion rules. Also some minor cleanups around the 1:N dialect conversion infrastructure, which did not always pass the type converter as a `const` object internally.
2024-10-05 21:32:40 +02:00
const fir::LLVMTypeConverter &converter, mlir::RewritePatternSet &patterns,
[flang][NFC] Expose FIR to LLVM patterns (#83492) The FIR dialect has been initiated before many interfaces have been introduced to MLIR. This patch expose the FIR to LLVM patterns in a `populateFIRToLLVMConversionPatterns` function. The idea is to be able to add the `ConvertToLLVMPatternInterface`. This is not directly possible since the FIR dialect does not currently use the table infrastructure for its definition. Follow up patches will move the FIR dialect definition to table gen and then implement the interface.
2024-03-04 00:11:59 -08:00
fir::FIRToLLVMPassOptions &options) {
patterns.insert<
AbsentOpConversion, AddcOpConversion, AddrOfOpConversion,
AllocaOpConversion, AllocMemOpConversion, BoxAddrOpConversion,
BoxCharLenOpConversion, BoxDimsOpConversion, BoxEleSizeOpConversion,
BoxIsAllocOpConversion, BoxIsArrayOpConversion, BoxIsPtrOpConversion,
BoxOffsetOpConversion, BoxProcHostOpConversion, BoxRankOpConversion,
BoxTypeCodeOpConversion, BoxTypeDescOpConversion, CallOpConversion,
[flang][NFC] remove unused fir.constc operation (#110821) As part of [RFC to replace fir.complex usages by mlir.complex type](https://discourse.llvm.org/t/rfc-flang-replace-usages-of-fir-complex-by-mlir-complex-type/82292). fir.constc is unused so instead of porting it, just remove it. Complex constants are currently created with inserts in lowering already. When using mlir complex, we may just want to start using [complex.constant](https://github.com/llvm/llvm-project/blob/4f6ad17adce1b87cadf0c896d3b38334045196ea/mlir/include/mlir/Dialect/Complex/IR/ComplexOps.td#L131C5-L131C16).
2024-10-02 16:16:57 +02:00
CmpcOpConversion, ConvertOpConversion, CoordinateOpConversion,
[flang] introduce fir.copy to avoid load store of aggregates (#130289) Introduce a FIR operation to do memcopy/memmove of compile time constant size types. This is to avoid requiring derived type copies to done with load/store which is badly supported in LLVM when the aggregate type is "big" (no threshold can easily be defined here, better to always avoid them for fir.type). This was the root cause of the regressions caused by #114002 which introduced a load/store of fir.type<> which caused hand/asserts to fire in LLVM on several benchmarks. See https://llvm.org/docs/Frontend/PerformanceTips.html#avoid-creating-values-of-aggregate-type
2025-03-11 09:31:03 +01:00
CopyOpConversion, DTEntryOpConversion, DeclareOpConversion,
DivcOpConversion, EmboxOpConversion, EmboxCharOpConversion,
EmboxProcOpConversion, ExtractValueOpConversion, FieldIndexOpConversion,
FirEndOpConversion, FreeMemOpConversion, GlobalLenOpConversion,
GlobalOpConversion, InsertOnRangeOpConversion, IsPresentOpConversion,
[flang] Remove materialization workaround in type converter (#98743) This change is in preparation of #97903, which adds extra checks for materializations: it is now enforced that they produce an SSA value of the correct type, so the current workaround no longer works. The original workaround avoided target materializations by directly returning the to-be-converted SSA value from the materialization callback. This can be avoided by initializing the lowering patterns that insert the materializations without a type converter. For `cg::XEmboxOp`, the existing workaround that skips `unrealized_conversion_cast` ops is still in place. Also remove the lowering pattern for `unrealized_conversion_cast`. This pattern has no effect because `unrealized_conversion_cast` ops that are inserted by the dialect conversion framework are never matched by the pattern driver.
2024-07-15 16:07:48 +02:00
LenParamIndexOpConversion, LoadOpConversion, MulcOpConversion,
NegcOpConversion, NoReassocOpConversion, SelectCaseOpConversion,
SelectOpConversion, SelectRankOpConversion, SelectTypeOpConversion,
ShapeOpConversion, ShapeShiftOpConversion, ShiftOpConversion,
SliceOpConversion, StoreOpConversion, StringLitOpConversion,
SubcOpConversion, TypeDescOpConversion, TypeInfoOpConversion,
UnboxCharOpConversion, UnboxProcOpConversion, UndefOpConversion,
UnreachableOpConversion, XArrayCoorOpConversion, XEmboxOpConversion,
XReboxOpConversion, ZeroOpConversion>(converter, options);
// Patterns that are populated without a type converter do not trigger
// target materializations for the operands of the root op.
patterns.insert<HasValueOpConversion, InsertValueOpConversion>(
patterns.getContext());
[flang][NFC] Expose FIR to LLVM patterns (#83492) The FIR dialect has been initiated before many interfaces have been introduced to MLIR. This patch expose the FIR to LLVM patterns in a `populateFIRToLLVMConversionPatterns` function. The idea is to be able to add the `ConvertToLLVMPatternInterface`. This is not directly possible since the FIR dialect does not currently use the table infrastructure for its definition. Follow up patches will move the FIR dialect definition to table gen and then implement the interface.
2024-03-04 00:11:59 -08:00
}
Reference in New Issue Copy Permalink