| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[flang][NFC] Strip trailing whitespace from tests (2 of N) Only the fortran source files in flang/test have been modified. The other files in the directory will be cleaned up in subsequent commits | 8 个月前 | |
[flang][NFC] use hlfir.declare first result when both results are raw pointers (#132261) Currently, the helpers to get fir::ExtendedValue out of hlfir::Entity use hlfir.declare second result ( #1) in most cases. This is because this result is the same as the input and matches what FIR was getting before lowering to HLFIR. But this creates odd situations when both hlfir.declare are raw pointers and either result ends-up being used in the IR depending on whether the code was generated by a helper using fir::ExtendedValue, or via "pure HLFIR" helpers using the first result. This will typically prevent simple CSE and easy identification that two operation (e.g load/store) are touching the exact same memory location without using alias analysis or "manual detection" (looking for common hlfir.declare defining op). Hence, when hlfir.declare results are both raw pointers, use #0 when producing fir::ExtendedValue. When #0 is a fir.box, keep using #1 because these are not the same. The only code change is in HLFIRTools.cpp and is pretty small, but there is a big test fallout of #1 to #0. | 1 年前 | |
[flang] add hlfir.all intrinsic Adds a new HLFIR operation for the ALL intrinsic according to the design set out in flang/docs/HighLevel.md Differential Revision: https://reviews.llvm.org/D151090 | 3 年前 | |
[flang][NFC] use hlfir.declare first result when both results are raw pointers (#132261) Currently, the helpers to get fir::ExtendedValue out of hlfir::Entity use hlfir.declare second result ( #1) in most cases. This is because this result is the same as the input and matches what FIR was getting before lowering to HLFIR. But this creates odd situations when both hlfir.declare are raw pointers and either result ends-up being used in the IR depending on whether the code was generated by a helper using fir::ExtendedValue, or via "pure HLFIR" helpers using the first result. This will typically prevent simple CSE and easy identification that two operation (e.g load/store) are touching the exact same memory location without using alias analysis or "manual detection" (looking for common hlfir.declare defining op). Hence, when hlfir.declare results are both raw pointers, use #0 when producing fir::ExtendedValue. When #0 is a fir.box, keep using #1 because these are not the same. The only code change is in HLFIRTools.cpp and is pretty small, but there is a big test fallout of #1 to #0. | 1 年前 | |
[flang] Change return type of reduction intrinsics Comments in the recent patch https://reviews.llvm.org/D149964, mentioned that using hlfir_ExprType in cases where intrinsics return simple scalars adds unnecessary abstraction that isn't needed unless an array type is being used. This patch modifies the HLFIR operations for product, sum and any so that they only return a hlfir_ExprType when the result is an array, otherwise they will return just the simple scalar type. Differential Revision: https://reviews.llvm.org/D150877 | 3 年前 | |
[flang][hlfir] Establish <storage, mustFree> tuple for ApplyOp and NoReassocOp. The bufferization pass must create the tuple for these operations, because the users may require it. For example, in case of ElementalOp inlining a DestroyOp may be generated for the operand of YieldElementOp, and the operand may be ApplyOp->NoReassocOp chain. Differential Revision: https://reviews.llvm.org/D150343 | 3 年前 | |
[flang] Add hlfir.apply definition hlfir.apply allows retrieving element values from an array expression value. See https://github.com/llvm/llvm-project/blob/main/flang/docs/HighLevelFIR.md for more detail. Differential Revision: https://reviews.llvm.org/D140023 | 3 年前 | |
[flang][hlfir] ensure hlfir.declare result box attributes are consistent (#143137) Prevent hlfir.declare output to be fir.box/class values with the heap/pointer attribute to ensure the runtime descriptor attributes are in line with the Fortran attributes for the entities being declared (only fir.ref<box/class> can be ALLOCATABLE/POINTERS). This fixes a bug where an associated entity inside a SELECT TYPE was being unexpectedly reallocated inside assign runtime because the selector was allocatable and this attribute was not properly removed when creating the descriptor for the associated entity (that does not inherit the ALLOCATABLE/POINTER attribute according to Fortran 2023 section 11.1.3.3). | 1 年前 | |
[flang][NFC] update createTempFromMold interface to return a bool (#162680) Some createTempFromMold users are looking for a compile time constant for the mustFree. Instead of having them retrieving it, update the interface to return a bool. The only users that needs a value was packageBufferizedExpr and it has an overload that accept bool too. Tests are updated to reflect that this changes the place where the boolean is created in BufferizeHLFIR, and just removes its creation in contexts it is not needed. | 9 个月前 | |
[flang][hlfir] Add move semantics to hlfir.as_expr. hlfir.as_expr allows turning an array, character, or derived type variable into a value when it the usage require an hlfir.expr (e.g, when returning the element value inside and hlfir.elemental). The default implementation of this operation in bufferization is to make a copy of the variable into a temporary buffer. This adds a time and memory overhead in cases where such copy is not needed because the variable is already a temporary that was created in lowering to compute the expression value, and the "as_expr" is the sole usage of the variable. This is for instance the case for many transformational intrinsics that do not have hlfir.expr operation (at least for now, but some may never benefit from having one) and must be implemented "on memory" in lowering. This patch adds a way to "move" the variable storage along its value. It allows the bufferization to re-use the variable storage for the hlfir.expr created by hlfir.as_expr, and in exchange, the responsibility of deallocating the buffer (if the variable was heap allocated) if passed along to the hlfir.expr, and will need to be done after the last hlfir.expr usage. Differential Revision: https://reviews.llvm.org/D141832 | 3 年前 | |
[flang][hlfir] Preserve hlfir.assign in the bufferize-hlfir pass hlfir.assign must be rewritten in the bufferize pass since its operands, that can be expressions, may have been updated. This is just an operand update rewrite. The previous code was replacing the operation, but it was dropping all hlfir.assign on the floor doing so. This broke allocatable assignment semantics that use attributes. Update the operands in place instead to preserve the attributes, if any. Differential Revision: https://reviews.llvm.org/D148310 | 3 年前 | |
[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. | 1 年前 | |
[flang][nfc] Use llvm memmove intrinsic over regular call (#134294) Follow up to #134170. We should be using the LLVM intrinsics instead of plain fir.calls when we can. Existing code creates a declaration for the llvm intrinsic and a regular fir.call, which makes it hard for consumers of the IR to find all the intrinsic calls. | 1 年前 | |
[mlir][vector] Fix attaching write effects on transfer_write's base (#142940) This fixes an issue with TransferWriteOp's implementation of the MemoryEffectOpInterface where the write effect was attached to the stored value rather than the base. This had the effect that when asking for the memory effects for the input memref buffer using getEffectsOnValue(...), the function would return no-effects (as the effect would have been attached to the stored value rather than the input buffer). | 1 年前 | |
[flang] replace fir.complex usages with mlir complex (#110850) Core patch of https://discourse.llvm.org/t/rfc-flang-replace-usages-of-fir-complex-by-mlir-complex-type/82292. After that, the last step is to remove fir.complex from FIR types. | 1 年前 | |
[flang][NFC] update createTempFromMold interface to return a bool (#162680) Some createTempFromMold users are looking for a compile time constant for the mustFree. Instead of having them retrieving it, update the interface to return a bool. The only users that needs a value was packageBufferizedExpr and it has an overload that accept bool too. Tests are updated to reflect that this changes the place where the boolean is created in BufferizeHLFIR, and just removes its creation in contexts it is not needed. | 9 个月前 | |
[flang] replace fir.complex usages with mlir complex (#110850) Core patch of https://discourse.llvm.org/t/rfc-flang-replace-usages-of-fir-complex-by-mlir-complex-type/82292. After that, the last step is to remove fir.complex from FIR types. | 1 年前 | |
[flang][debug] Track dummy argument positions explicitly. (#167489) CHARACTER dummy arguments were treated as local variables in debug info. This happened because our method to get the argument number was not robust. It relied on DeclareOp having a direct reference to arguments which was not the case for character arguments. This is fixed by storing source-level argument positions in DeclareOp. Fixes #112886 | 8 个月前 | |
[flang][debug] Track dummy argument positions explicitly. (#167489) CHARACTER dummy arguments were treated as local variables in debug info. This happened because our method to get the argument number was not robust. It relied on DeclareOp having a direct reference to arguments which was not the case for character arguments. This is fixed by storing source-level argument positions in DeclareOp. Fixes #112886 | 8 个月前 | |
[flang][debug] Track dummy argument positions explicitly. (#167489) CHARACTER dummy arguments were treated as local variables in debug info. This happened because our method to get the argument number was not robust. It relied on DeclareOp having a direct reference to arguments which was not the case for character arguments. This is fixed by storing source-level argument positions in DeclareOp. Fixes #112886 | 8 个月前 | |
[flang] Do not produce result for void runtime call (#123155) Runtime function call to a void function are producing a ssa value because the FunctionType result is set to NoneType with is later translated to a empty struct. This is not an issue when going to LLVM IR but it breaks when lowering a gpu module to PTX. This patch update the RTModel to correctly set the FunctionType result type to nothing. This is one runtime call before this patch at the LLVM IR dialect step. %45 = llvm.call @_FortranAAssign(%arg0, %1, %44, %4) : (!llvm.ptr, !llvm.ptr, !llvm.ptr, i32) -> !llvm.struct<()> After the patch the call would be correctly formed llvm.call @_FortranAAssign(%arg0, %1, %44, %4) : (!llvm.ptr, !llvm.ptr, !llvm.ptr, i32) -> () Without the patch it would lead to error like: ptxas /tmp/mlir-cuda_device_mod-nvptx64-nvidia-cuda-sm_60-e804b6.ptx, line 10; error : Output parameter cannot be an incomplete array. ptxas /tmp/mlir-cuda_device_mod-nvptx64-nvidia-cuda-sm_60-e804b6.ptx, line 125; error : Call has wrong number of parameters The change is pretty much mechanical. | 1 年前 | |
[flang] Do not produce result for void runtime call (#123155) Runtime function call to a void function are producing a ssa value because the FunctionType result is set to NoneType with is later translated to a empty struct. This is not an issue when going to LLVM IR but it breaks when lowering a gpu module to PTX. This patch update the RTModel to correctly set the FunctionType result type to nothing. This is one runtime call before this patch at the LLVM IR dialect step. %45 = llvm.call @_FortranAAssign(%arg0, %1, %44, %4) : (!llvm.ptr, !llvm.ptr, !llvm.ptr, i32) -> !llvm.struct<()> After the patch the call would be correctly formed llvm.call @_FortranAAssign(%arg0, %1, %44, %4) : (!llvm.ptr, !llvm.ptr, !llvm.ptr, i32) -> () Without the patch it would lead to error like: ptxas /tmp/mlir-cuda_device_mod-nvptx64-nvidia-cuda-sm_60-e804b6.ptx, line 10; error : Output parameter cannot be an incomplete array. ptxas /tmp/mlir-cuda_device_mod-nvptx64-nvidia-cuda-sm_60-e804b6.ptx, line 125; error : Call has wrong number of parameters The change is pretty much mechanical. | 1 年前 | |
[flang][NFC] update createTempFromMold interface to return a bool (#162680) Some createTempFromMold users are looking for a compile time constant for the mustFree. Instead of having them retrieving it, update the interface to return a bool. The only users that needs a value was packageBufferizedExpr and it has an overload that accept bool too. Tests are updated to reflect that this changes the place where the boolean is created in BufferizeHLFIR, and just removes its creation in contexts it is not needed. | 9 个月前 | |
[flang] Introduce hlfir.elemental lowerings to omp.workshare_loop_nest (#104748) This patch adds parallelization support for the following expression in OpenMP workshare constructs: * Elemental procedures in array expressions (reapplied with linking fix) | 1 年前 | |
[flang] Do not produce result for void runtime call (#123155) Runtime function call to a void function are producing a ssa value because the FunctionType result is set to NoneType with is later translated to a empty struct. This is not an issue when going to LLVM IR but it breaks when lowering a gpu module to PTX. This patch update the RTModel to correctly set the FunctionType result type to nothing. This is one runtime call before this patch at the LLVM IR dialect step. %45 = llvm.call @_FortranAAssign(%arg0, %1, %44, %4) : (!llvm.ptr, !llvm.ptr, !llvm.ptr, i32) -> !llvm.struct<()> After the patch the call would be correctly formed llvm.call @_FortranAAssign(%arg0, %1, %44, %4) : (!llvm.ptr, !llvm.ptr, !llvm.ptr, i32) -> () Without the patch it would lead to error like: ptxas /tmp/mlir-cuda_device_mod-nvptx64-nvidia-cuda-sm_60-e804b6.ptx, line 10; error : Output parameter cannot be an incomplete array. ptxas /tmp/mlir-cuda_device_mod-nvptx64-nvidia-cuda-sm_60-e804b6.ptx, line 125; error : Call has wrong number of parameters The change is pretty much mechanical. | 1 年前 | |
[flang][hlfir] Fix c_null_ptr lowering in structure constructors (#68321) Lowering handles C_PTR initial values that are designators or NULL() inside structure constructors as an extension to support. This extension is used by initial values generated for runtime derived type info. But c_null_ptr wrongly fell into this extension path with HLFIR, causing the initial value to be set to some (non null) address containing c_null_ptr instead of c_null_ptr itself... This was caused by the FIR lowering relying on genExtAddrInInitializer to not place c_null_ptr inside an address. Fix this by only falling through into the extension handling code if this is an extension: i.e, the expression is some designated symbol or NULL(). | 2 年前 | |
[flang][debug] Track dummy argument positions explicitly. (#167489) CHARACTER dummy arguments were treated as local variables in debug info. This happened because our method to get the argument number was not robust. It relied on DeclareOp having a direct reference to arguments which was not the case for character arguments. This is fixed by storing source-level argument positions in DeclareOp. Fixes #112886 | 8 个月前 | |
[flang][debug] Track dummy argument positions explicitly. (#167489) CHARACTER dummy arguments were treated as local variables in debug info. This happened because our method to get the argument number was not robust. It relied on DeclareOp having a direct reference to arguments which was not the case for character arguments. This is fixed by storing source-level argument positions in DeclareOp. Fixes #112886 | 8 个月前 | |
[flang][hlfir] Fixed length-one assignment. Assignment from a character dummy argument to a length-one character variable resulted in illegal fir.convert: %0 = fir.load %unboxed_dummy : !fir.ref<!fir.char<1,?>> %1 = fir.convert %0 : (!fir.char<1,?>) -> !fir.char<1> fir.store %1 to %local : !fir.ref<!fir.char<1>> This change fixes the length-one assignment code to use proper casts. For character dummy arguments with constant length we will now also type cast the unboxed reference to the character type with constant length during the lowering: fir.convert %x : (!fir.ref<!fir.char<1,?>>) -> !fir.ref<!fir.char<1,8>> I also adjusted the length-one assignment recognition so that in case of same-length assignment we recognize length-one from either LHS or RHS data types. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D149382 | 3 年前 | |
[flang][nfc] Use llvm memmove intrinsic over regular call (#134294) Follow up to #134170. We should be using the LLVM intrinsics instead of plain fir.calls when we can. Existing code creates a declaration for the llvm intrinsic and a regular fir.call, which makes it hard for consumers of the IR to find all the intrinsic calls. | 1 年前 | |
[flang][hlfir] hlfir.char_extremum op definition and codegen This patch adds an hlfir operation called char_extremum, which takes the lexicographic comparison between a variadic number (minimum of 2 arguments) of characters. Discussion for this work can be found in the draft revision found [here](https://reviews.llvm.org/D143326). The reason I'm not promoting that draft to a true patch for review was because I needed to separate out the op definition/codegen and lowering as two separate patches, as preferred by @jeanPerier. Differential Revision: https://reviews.llvm.org/D152474 | 3 年前 | |
[flang] Replace lowering of character compare. (#155458) Lower character comparison into hlfir.cmpchar operation and then lower the operation into a runtime call at intrinsic lowering. | 11 个月前 | |
[flang][nfc] Use llvm memmove intrinsic over regular call (#134294) Follow up to #134170. We should be using the LLVM intrinsics instead of plain fir.calls when we can. Existing code creates a declaration for the llvm intrinsic and a regular fir.call, which makes it hard for consumers of the IR to find all the intrinsic calls. | 1 年前 | |
[flang] Add hlfir.concat operation definition This operation represents scalar character concatenation. This is added as part of flang lowering update described in https://github.com/llvm/llvm-project/blob/main/flang/docs/HighLevelFIR.md A notable difference with Fortran concatenation is that hlfir.concat can take two or more operands. This will be used to optimize concatenation chains. Differential Revision: https://reviews.llvm.org/D138650 | 3 年前 | |
[flang][openacc] Added acc::RecipeInterface for getting alloca insertion point. (#68464) Conversion of hlfir.assign operations inside OpenACC recipe operations may result in fir.alloca insertion. FIRBuilder can only handle alloca insertion inside FuncOp's and outlineable OpenMP operations. I added a simple interface for OpenACC recipe operations that have executable code inside all their regions, and alloca may be inserted into the entry blocks of those regions always. With our current approach the OptimizedBufferization pass is supposed to lower these hlfir.assign operations into loops, because there should not be conflicts between lhs/rhs. The pass is currently only working on FuncOp, and this is why it does not optimize hlfir.assign inside the recipes. I will fix it in a separate commit. Since we run OptimizedBufferization only at >O0, these changes should still be useful. Note that the OpenACC codegen that applies the recipes should be aware of potential alloca operations and produce appropriate stack clean-ups. | 2 年前 | |
[flang] Do not produce result for void runtime call (#123155) Runtime function call to a void function are producing a ssa value because the FunctionType result is set to NoneType with is later translated to a empty struct. This is not an issue when going to LLVM IR but it breaks when lowering a gpu module to PTX. This patch update the RTModel to correctly set the FunctionType result type to nothing. This is one runtime call before this patch at the LLVM IR dialect step. %45 = llvm.call @_FortranAAssign(%arg0, %1, %44, %4) : (!llvm.ptr, !llvm.ptr, !llvm.ptr, i32) -> !llvm.struct<()> After the patch the call would be correctly formed llvm.call @_FortranAAssign(%arg0, %1, %44, %4) : (!llvm.ptr, !llvm.ptr, !llvm.ptr, i32) -> () Without the patch it would lead to error like: ptxas /tmp/mlir-cuda_device_mod-nvptx64-nvidia-cuda-sm_60-e804b6.ptx, line 10; error : Output parameter cannot be an incomplete array. ptxas /tmp/mlir-cuda_device_mod-nvptx64-nvidia-cuda-sm_60-e804b6.ptx, line 125; error : Call has wrong number of parameters The change is pretty much mechanical. | 1 年前 | |
[flang] Simplify copy-in copy-out runtime API (#95822) The runtime API for copy-in copy-out currently only has an entry only for the copy-out. This entry has a "skipInit" boolean that is never set to false by lowering and it does not deal with the deallocation of the temporary. The generated code was a mix of inline code and runtime calls This is not a big deal, but this is unneeded compiler and generated code complexity. With assumed-rank, it is also more cumbersome to establish a temporary descriptor. Instead, this patch: - Adds a CopyInAssignment API that deals with establishing the temporary descriptor and does the copy. - Removes unused arg to CopyOutAssign, and pushes destruction/deallocation responsibility inside it. Note that this runtime API are still not responsible for deciding the need of copying-in and out. This is kept as a separate runtime call to IsContiguous, which is easier to inline/replace by inline code with the hope of removing the copy-in/out calls after user function inlining. @vzakhari has already shown that always inlining all the copy part increase Fortran compilation time due to loop optimization attempts for loops that are known to have little optimization profitability (the variable being copied from and to is not contiguous). | 2 年前 | |
[flang] Do not produce result for void runtime call (#123155) Runtime function call to a void function are producing a ssa value because the FunctionType result is set to NoneType with is later translated to a empty struct. This is not an issue when going to LLVM IR but it breaks when lowering a gpu module to PTX. This patch update the RTModel to correctly set the FunctionType result type to nothing. This is one runtime call before this patch at the LLVM IR dialect step. %45 = llvm.call @_FortranAAssign(%arg0, %1, %44, %4) : (!llvm.ptr, !llvm.ptr, !llvm.ptr, i32) -> !llvm.struct<()> After the patch the call would be correctly formed llvm.call @_FortranAAssign(%arg0, %1, %44, %4) : (!llvm.ptr, !llvm.ptr, !llvm.ptr, i32) -> () Without the patch it would lead to error like: ptxas /tmp/mlir-cuda_device_mod-nvptx64-nvidia-cuda-sm_60-e804b6.ptx, line 10; error : Output parameter cannot be an incomplete array. ptxas /tmp/mlir-cuda_device_mod-nvptx64-nvidia-cuda-sm_60-e804b6.ptx, line 125; error : Call has wrong number of parameters The change is pretty much mechanical. | 1 年前 | |
[flang][NFC] use hlfir.declare first result when both results are raw pointers (#132261) Currently, the helpers to get fir::ExtendedValue out of hlfir::Entity use hlfir.declare second result ( #1) in most cases. This is because this result is the same as the input and matches what FIR was getting before lowering to HLFIR. But this creates odd situations when both hlfir.declare are raw pointers and either result ends-up being used in the IR depending on whether the code was generated by a helper using fir::ExtendedValue, or via "pure HLFIR" helpers using the first result. This will typically prevent simple CSE and easy identification that two operation (e.g load/store) are touching the exact same memory location without using alias analysis or "manual detection" (looking for common hlfir.declare defining op). Hence, when hlfir.declare results are both raw pointers, use #0 when producing fir::ExtendedValue. When #0 is a fir.box, keep using #1 because these are not the same. The only code change is in HLFIRTools.cpp and is pretty small, but there is a big test fallout of #1 to #0. | 1 年前 | |
[flang][hlfir] Add hlfir.count intrinsic Adds a new HLFIR operation for the COUNT intrinsic according to the design set out in flang/docs/HighLevel.md. This patch includes all the necessary changes to create a new HLFIR operation and lower it into the fir runtime call. Author was @jacob-crawley. Minor adjustments by @tblah Differential Revision: https://reviews.llvm.org/D152521 | 3 年前 | |
[flang][NFC] use hlfir.declare first result when both results are raw pointers (#132261) Currently, the helpers to get fir::ExtendedValue out of hlfir::Entity use hlfir.declare second result ( #1) in most cases. This is because this result is the same as the input and matches what FIR was getting before lowering to HLFIR. But this creates odd situations when both hlfir.declare are raw pointers and either result ends-up being used in the IR depending on whether the code was generated by a helper using fir::ExtendedValue, or via "pure HLFIR" helpers using the first result. This will typically prevent simple CSE and easy identification that two operation (e.g load/store) are touching the exact same memory location without using alias analysis or "manual detection" (looking for common hlfir.declare defining op). Hence, when hlfir.declare results are both raw pointers, use #0 when producing fir::ExtendedValue. When #0 is a fir.box, keep using #1 because these are not the same. The only code change is in HLFIRTools.cpp and is pretty small, but there is a big test fallout of #1 to #0. | 1 年前 | |
[flang][hlfir] ensure hlfir.declare result box attributes are consistent (#143137) Prevent hlfir.declare output to be fir.box/class values with the heap/pointer attribute to ensure the runtime descriptor attributes are in line with the Fortran attributes for the entities being declared (only fir.ref<box/class> can be ALLOCATABLE/POINTERS). This fixes a bug where an associated entity inside a SELECT TYPE was being unexpectedly reallocated inside assign runtime because the selector was allocatable and this attribute was not properly removed when creating the descriptor for the associated entity (that does not inherit the ALLOCATABLE/POINTER attribute according to Fortran 2023 section 11.1.3.3). | 1 年前 | |
[flang][HLFIR] add skip_rebox option to hlfir.declare (#162305) hlfir.declare with a fir.box input always lead to a fir.rebox being created to ensure the lower bounds and attributes are set correctly in the local descriptor for the entity. This is really needed for hlfir.declare using fir.box function argument that do not come with any guarantees with regards to the lower bounds. Sometimes however, this fir.rebox just adds a lot of noise in the SSA chain, especially at the LLVM level and it is known that the input descriptor is already correct. I am making this patch in the context of OpenACC where I want to remap the variables inside the compute region, creating a fir.rebox on the way. This fir.rebox cannot be optimized away by FIR because of the OpenACC ops in the SSA chain. This patch adds a flag to indicate the the fir.box is known to have the correct lower bounds and attributes so that it can have a simpler code generation to FIR. | 9 个月前 | |
[flang] Added storage specification for [hl]fir.declare. (#155325) As proposed in https://discourse.llvm.org/t/rfc-flang-representation-for-objects-inside-physical-storage/88026, this patch adds a storage Value operand and a storage_offset Integer attribute for [hl]fir.declare operations. The storage operand indicates the raw address of the physical storage a variable belongs to. This is the beginning address of the physical storage. The storage_offset specifies a byte offset within the physical storage where the variable object starts. | 11 个月前 | |
[flang] replace fir.complex usages with mlir complex (#110850) Core patch of https://discourse.llvm.org/t/rfc-flang-replace-usages-of-fir-complex-by-mlir-complex-type/82292. After that, the last step is to remove fir.complex from FIR types. | 1 年前 | |
[flang] Convert hlfir.designate with comp and contiguous result. (#154232) Array sections like this have not been using the knowledge that the result is contiguous: type t integer :: f end type type(t) :: a(:) a%f = 0 Peter Klausler is working on a change that will result in the corresponding hlfir.designate having a component and a non-box result. This patch fixes the issues found in HLFIR-to-FIR conversion. | 11 个月前 | |
[flang] Fixed designator codegen for contiguous boxes. (#139003) Contiguous variables represented with a box do not have explicit shape, but it looks like the base/shape computation was assuming that. This caused generation of raw address fir.array_coor without the shape. This patch is needed to fix failures hapenning with #138797. | 1 年前 | |
[flang] replace fir.complex usages with mlir complex (#110850) Core patch of https://discourse.llvm.org/t/rfc-flang-replace-usages-of-fir-complex-by-mlir-complex-type/82292. After that, the last step is to remove fir.complex from FIR types. | 1 年前 | |
[flang] Lower elemental and transformational clean-up in HLFIR In lowering to hlfir, no clean-up was added yet for the created hlfir.elemental. Add the needed hlfir.destroy. Regarding transformational lowering, clean-ups were created because they are lowered in memory, but this is inconvenient because this prevented lowering to hlfir from "moving" the created variable to an expression. Add a new entry point in IntrinsicCall.h that keeps track of whether or not the returned storage needs to be deallocated, but does not insert the deallocation in the StatementContext. This allows using the newly added hlfir.as_expr "move" aspect to be used and save creating a copy. Depends on D141839 Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D141841 | 3 年前 | |
[flang][hlfir] Fixed some finalization/deallocation issues. (#67047) This set of commits resolves some of the issues with elemental calls producing results that may require finalization, and also some memory leak issues due to the missing deallocation of allocatable components of the temporary buffers created by the bufferization pass. - [flang][runtime] Expose Finalize API for derived types. - [flang][hlfir] Add 'finalize' attribute for DestroyOp. - [flang][hlfir] Postpone result finalization for elemental calls. The results of elemental calls generated inside hlfir.elemental must not be finalized/destructed before they are copied into the resulting array. The finalization must be done on the array as a whole (e.g. there might be different scalar and array finalization routines). The finalization work is left to the hlfir.destroy corresponding to this hlfir.elemental. - [flang][hlfir] Tighten requirements on hlfir.end_associate operand. If component deallocation might be required for the operand of hlfir.end_associate, we have to be able to get the variable shape/params to create a descriptor for calling the runtime. This commit adds verification that we can do so. - [flang][hlfir] Lower argument clean-ups using valid hlfir.end_associate. The operand must be a Fortran entity, when allocatable component deallocation may be required. - [flang][hlfir] Properly clean-up temporary buffers in bufferization pass. This commit combines changes for proper finalization and component deallocation of the temporary buffers. The finalization part relates to hlfir.destroy operations with 'finalize' attribute. The component deallocation might be invoked for both hlfir.destroy and hlfir.end_associate, if the operand is of a derived type with allocatable component(s). The changes are mostly in one function, so I decided not to split them. - [flang][hlfir] Disable optimizations for hlfir.elemental requiring finalization. If hlfir.elemental is coupled with hlfir.destroy with 'finalize' attribute, the temporary array result of hlfir.elemental needs to be created for the purpose of finalization. We cannot do certain optimizations on such hlfir.elemental operations. I was not able to come up with a test for the OptimizedBufferization pass, but I put the check there as well. | 2 年前 | |
[flang][NFC] use hlfir.declare first result when both results are raw pointers (#132261) Currently, the helpers to get fir::ExtendedValue out of hlfir::Entity use hlfir.declare second result ( #1) in most cases. This is because this result is the same as the input and matches what FIR was getting before lowering to HLFIR. But this creates odd situations when both hlfir.declare are raw pointers and either result ends-up being used in the IR depending on whether the code was generated by a helper using fir::ExtendedValue, or via "pure HLFIR" helpers using the first result. This will typically prevent simple CSE and easy identification that two operation (e.g load/store) are touching the exact same memory location without using alias analysis or "manual detection" (looking for common hlfir.declare defining op). Hence, when hlfir.declare results are both raw pointers, use #0 when producing fir::ExtendedValue. When #0 is a fir.box, keep using #1 because these are not the same. The only code change is in HLFIRTools.cpp and is pretty small, but there is a big test fallout of #1 to #0. | 1 年前 | |
[flang][hlfir] Add hlfir.dot_product intrinsic Adds a new HLFIR operation for the DOT_PRODUCT intrinsic according to the design set out in flang/docs/HighLevel.md. This patch includes all the necessary changes to create a new HLFIR operation and lower it into the fir runtime call. Differential Revision: https://reviews.llvm.org/D152252 | 3 年前 | |
[flang] Recognize unused dummy arguments during lowering with HLFIR. So far we've relied on AllocaOp to represent the dummy arguments not declared for the current entry. With HLFIR we have to account for hlfir::DeclareOp. Differential Revision: https://reviews.llvm.org/D149231 | 3 年前 | |
[flang] Added fir.dummy_scope operation to preserve dummy arguments association. (#90642) The new operation is just an abstract attribute that is attached to [hl]fir.declare operations of dummy arguments of a subroutine. Dummy arguments of the same subroutine refer to the same fir.dummy_scope, so they can be recognized as such during FIR AliasAnalysis. Note that the fir.dummy_scope must be specific to the runtime instantiation of a subroutine, so any MLIR inlining/cloning should duplicate and unique it vs using the same fir.dummy_scope for different runtime instantiations. This is why I made it an operation rather than an attribute. The new operation uses a write effect on DebuggingResource, same as [hl]fir.declare, to avoid optimizing it away. | 2 年前 | |
[flang] lower vector subscripted polymorphic designators (#84778) A mold argument need to be added to the hlfir.element_addr and set in lowering so that when the hlfir.element_addr need to be turned into an hlfir.elemental operation because the designator must be turned into a value, the mold can be set on the hlfir.elemental to later allocate the temporary according the the dynamic type. This situation happens whenever the vector subscripted polymorphic designator does not appear as an assignment left-hand side, or as an IO-input item. I initially thought retrieving the mold would be tricky if the dynamic type of the designator was set by a part-ref of the right of the vector subscripts ("array(vector)%polymorphic_comp"), but this turned out to be impossible because: 1. A derived type component can be polymorphic only if it has the POINTER or ALLOCATABLE attribute (F2023 C708). 2. Vector-subscripted part are ranked and F2023 C919 prohibits any part-ref on the right of the rank part to have the POINTER or ALLOCATABLE attribute. => If a vector subscripted designator is polymorphic, the vector subscripted part is the rightmost part, and the mold is the base of the vector subscripted part. This makes the retrieval of the mold easy in lowering. The mold argument is always set to be the base of the vector subscripted part when lowering the vector subscripted part, and it is removed at the end of the designator lowering if the designator is not polymorphic. This way there is no need to find back the mold from the inside of the hlfir.element_addr body. | 2 年前 | |
[flang][NFC] update createTempFromMold interface to return a bool (#162680) Some createTempFromMold users are looking for a compile time constant for the mustFree. Instead of having them retrieving it, update the interface to return a bool. The only users that needs a value was packageBufferizedExpr and it has an overload that accept bool too. Tests are updated to reflect that this changes the place where the boolean is created in BufferizeHLFIR, and just removes its creation in contexts it is not needed. | 9 个月前 | |
[flang][NFC] use hlfir.declare first result when both results are raw pointers (#132261) Currently, the helpers to get fir::ExtendedValue out of hlfir::Entity use hlfir.declare second result ( #1) in most cases. This is because this result is the same as the input and matches what FIR was getting before lowering to HLFIR. But this creates odd situations when both hlfir.declare are raw pointers and either result ends-up being used in the IR depending on whether the code was generated by a helper using fir::ExtendedValue, or via "pure HLFIR" helpers using the first result. This will typically prevent simple CSE and easy identification that two operation (e.g load/store) are touching the exact same memory location without using alias analysis or "manual detection" (looking for common hlfir.declare defining op). Hence, when hlfir.declare results are both raw pointers, use #0 when producing fir::ExtendedValue. When #0 is a fir.box, keep using #1 because these are not the same. The only code change is in HLFIRTools.cpp and is pretty small, but there is a big test fallout of #1 to #0. | 1 年前 | |
[flang][hlfir] ensure hlfir.declare result box attributes are consistent (#143137) Prevent hlfir.declare output to be fir.box/class values with the heap/pointer attribute to ensure the runtime descriptor attributes are in line with the Fortran attributes for the entities being declared (only fir.ref<box/class> can be ALLOCATABLE/POINTERS). This fixes a bug where an associated entity inside a SELECT TYPE was being unexpectedly reallocated inside assign runtime because the selector was allocatable and this attribute was not properly removed when creating the descriptor for the associated entity (that does not inherit the ALLOCATABLE/POINTER attribute according to Fortran 2023 section 11.1.3.3). | 1 年前 | |
[flang][hlfir] Apply MemAlloc effect to hlfir.elemental explicitly. Related to https://github.com/llvm/llvm-project/issues/64866. This patch effectively disables CSE for identical hlfir.elemental operations, because it causes hlfir.destroy to be applied twice to the same temporary. Moreover, I think MemAlloc is correct for hlfir.elemental, in general. Reviewed By: tblah Differential Revision: https://reviews.llvm.org/D158565 | 2 年前 | |
[flang][hlfir] Shallow copy elemental results with allocatable components. (#68040) To avoid the overhead of deallocating allocatable components of the elemental temporary result on every iteration of the elemental operation, we can use a shallow copy instead of deep-copy assign. | 2 年前 | |
[flang] Reset all extents to zero for empty hlfir.elemental loops. (#124867) An hlfir.elemental with a shape (0, HUGE) still runs HUGE number of iterations when expanded into a loop nest. HLFIR transformational operations inlined as hlfir.elemental may execute slower comparing to Fortran runtime implementation. This patch adds an option for BufferizeHLFIR pass to reset all upper bounds in the elemental loop nests to zero, if the result is an empty array. A separate patch will enable this option in the driver after I do more performance testing. The option is off by default now. | 1 年前 | |
[flang][hlfir] Support mold operand for hlfir.elemental. To properly create temporary array for a polymorphic result of hlfir.elemental we need to keep the mold as its operand. This patch adds just the basic support. Reviewed By: clementval, tblah Differential Revision: https://reviews.llvm.org/D157315 | 2 年前 | |
[flang][hlfir] Add assignment mask operations Add hlfir.forall_mask, hlfir.where, and hlfir.elsewhere operations that are operations that holds (optionally for hlfir.elsewhere) the evaluation of a logical mask that controls the evaluation of nested operations. They allow representing Fortran forall control mask, as well as where and eslewhere statements/constructs. They use the OrderedAssignmentTreeOpInterface since they can all be used inside Forall and their masks should be fully evaluated for all the index-value set induced by parent Forall before any of the nested operations in their body is evaluated. I initially tried making them into a single operation with some attributes to make a difference, but I felt this made the verifier/parser/printer and usages messier/tricky compared to making three distinct operations that represent the three Fortran feature in a vanilla way. Differential Revision: https://reviews.llvm.org/D149754 | 3 年前 | |
[flang] Lower hlfir.eoshift to the runtime call. (#153107) Straightforward lowering of hlfir.eoshift to the runtime call in LowerHLFIRIntrinsics pass. | 11 个月前 | |
[flang][hlfir] add hlfir.eval_in_mem operation (#118067) See HLFIROps.td change for the description of the operation. The goal is to ease temporary storage elision for expression evaluation (typically evaluating the RHS directly inside the LHS) for expressions that do not have abtsractions in HLFIR and for which it is not clear adding one would bring much. The case that is implemented in [the following lowering patch](https://github.com/llvm/llvm-project/pull/118070) is the array call case, where adding a new hlfir.call would add complexity (needs to deal with dispatch, inlining ....). | 1 年前 | |
[flang][hlfir] add hlfir.eval_in_mem operation (#118067) See HLFIROps.td change for the description of the operation. The goal is to ease temporary storage elision for expression evaluation (typically evaluating the RHS directly inside the LHS) for expressions that do not have abtsractions in HLFIR and for which it is not clear adding one would bring much. The case that is implemented in [the following lowering patch](https://github.com/llvm/llvm-project/pull/118070) is the array call case, where adding a new hlfir.call would add complexity (needs to deal with dispatch, inlining ....). | 1 年前 | |
[flang] Add High level Fortran IR dialect This patch adds the basic dialect definition of the HLFIR dialect that was described in https://reviews.llvm.org/D134285. It adds the definition of the hlfir.expr type and related tests so that it can be verified that the dialect is properly hooked up by the tools. Operations will be added as progress is made in the expression lowering update. Differential Revision: https://reviews.llvm.org/D136328 | 3 年前 | |
[flang] Simplify the comparison of characters (#154593) Because character comparison appends spaces to the shorter character, calls to trim() that are used only in the comparison can be eliminated. Example: trim(x) == trim(y) can be simplified to x == y This makes 527.cam4_r about 3% faster, measured on Neoverse V2. This patch implements the optimization above in a new pass: ExpressionSimplification. Although no other expression simplifications are planned at the moment, they could be easily added to the new pass. The ExpressionSimplification pass runs early in the HLFIR pipeline, to make it easy to identify expressions before any transformations occur. | 10 个月前 | |
[flang][HLFIR] Use GreedyPatternRewriter in LowerHLFIRIntrinsics (#83438) In #83253 @matthias-springer pointed out that LowerHLFIRIntrinsics.cpp should not be using rewrite patterns with the dialect conversion driver. The intention of this pass is to lower HLFIR intrinsic operations into FIR so it conceptually fits dialect conversion. However, dialect conversion is much stricter about changing types when replacing operations. This pass sometimes looses track of array bounds, resulting in replacements with operations with different but compatible types (expressions of the same rank and element types but with or without compile time known array bounds). This is difficult to accommodate with the dialect conversion driver and so I have changed to use the greedy pattern rewriter. There is a lot of test churn because the greedy pattern rewriter also performs canonicalization. | 2 年前 | |
[flang][fir] Provide allocation block for fir.local when required (#144521) Extends fir::FirOpBuilder::getAllocaBlock() to support fir.local. This allows us to retrieve an allocation block when needed for fir.local. | 1 年前 | |
[flang][do concurrent] Extned getAllocaBlock() and emit yields correctly (#146853) Handles some loose ends in do concurrent reduction declarations. This PR extends getAllocaBlock to handle declare ops, and also emit fir.yield in all regions. | 1 年前 | |
[flang][hlfir] Only canonicalize forall_index if it can be erased It seems the canonicalization was not correct: it cannot return that it failed if it did modify the IR. This was exposed by a new MLIR sanity check added in https://reviews.llvm.org/D144552. I am not sure it is legit to return success if the operation being canonicalized is not modified either. So only remove the loads if they are the only uses of the forall_index. Should fix (intermittent?) bot failures like https://lab.llvm.org/buildbot/#/builders/179/builds/6251 since the new MLIR check was added. Differential Revision: https://reviews.llvm.org/D151487 | 3 年前 | |
[flang][hlfir] Add hlfir.forall and its OrderAssignmentTreeOpInterface This patch adds the hlfir.forall operation and the OrderAssignmentTreeOpInterface that allows representing Fortran forall. It uses regions to keep Fortran expression evaluation independent from each other in the IR. Forall assignments inside hlfir.forall are represented with hlfir.region_assign which also keeps the IR generated for each expressions independently. The goal of this representation is to provide a representation that is straightforward to generate from Fortran parse tree without any analysis, while providing enough structure information so that an optimization pass can decide how to schedule, and save if needed, the evaluations of the Forall and Where expression and statements. It allows the data dependency analysis to be done at the HLFIR level. The OrderAssignmentTreeOpInterface allows ensuring that the Forall/Where tree structure is kept in the IR. It will allow visiting this tree in the IR without hard coding the operation structures in the pass. Differential Revision: https://reviews.llvm.org/D149734 | 3 年前 | |
[flang][hlfir] Add assignment mask operations Add hlfir.forall_mask, hlfir.where, and hlfir.elsewhere operations that are operations that holds (optionally for hlfir.elsewhere) the evaluation of a logical mask that controls the evaluation of nested operations. They allow representing Fortran forall control mask, as well as where and eslewhere statements/constructs. They use the OrderedAssignmentTreeOpInterface since they can all be used inside Forall and their masks should be fully evaluated for all the index-value set induced by parent Forall before any of the nested operations in their body is evaluated. I initially tried making them into a single operation with some attributes to make a difference, but I felt this made the verifier/parser/printer and usages messier/tricky compared to making three distinct operations that represent the three Fortran feature in a vanilla way. Differential Revision: https://reviews.llvm.org/D149754 | 3 年前 | |
[flang][hlfir] Added hlfir.get_length to inquire char length from hlfir.expr. We will use hlfir.get_length to lower inquiries of char length applied to hlfir.expr character values. Reviewed By: tblah, jeanPerier Differential Revision: https://reviews.llvm.org/D154560 | 3 年前 | |
[flang] Allow non-index length parameter on exprs fed into hlfir.get_length. (#124827) The length might be any integer, so hlfir.get_length lowering should explicitly cast it to index. | 1 年前 | |
[flang] Support non-index shape in hlfir.get_extent codegen. (#124622) hlfir.reshape inlining uncovered an existing bug that non-index shapes result in failures during hlfir.get_extent conversion to FIR. I could have "fixed" the shape during hlfir.reshape inlining, but this seems like a better fix. | 1 年前 | |
[flang][hlfir] add hlfir.get_extent This operation fetches an extent value from a fir.shape. The operation could just as easily live in the fir namespace, but is only needed for hlfir lowering so I put it here. This operation is required to allow one to defer getting the extents of a shape generated by hlfir.get_shape until after that shape has been resolved (after bufferization of the hlfir.expr). This operation will be lowered to FIR as an arith.constant created using the definition of the fir.shape argument. Depends on: D146830 Differential Revision: https://reviews.llvm.org/D148220 | 3 年前 | |
[flang][driver] rename flang-new to flang (#110023) This does a global rename from flang-new to flang. I also removed/changed any TODOs that I found related to making this change. --------- Co-authored-by: H. Vetinari <h.vetinari@gmx.com> Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> | 1 年前 | |
[flang] Add hlfir.index op to represent index intrinsic function (#157575) The change adds a new HLFIR operation. A call to index intrinsic now becomes lowered into the hlfir.index op and then naive lowering of the op translates it back to appropriate runtime call. The change set is aimed to be functionally equivalent to exiting index functionality, but is much more efficient in a case of presence of the 'kind' intrinsic parameter. Also fixed couple of parameter lowering issues which were revealed while working on the index-related functional parts. | 10 个月前 | |
[flang][hlfir] fix regression in inline elementals InlineElementals created a regression when inlining elemental expressions where the type of the result of the hlfir.apply does not match the hlfir.yield. This patch ensures the pass doesn't match in these cases, fixing the regression. It isn't clear to me what the /right/ solution is: - Is it actually valid for the hlfir.apply to have a different type (even just different array bounds?). Should this be enforced in the verifier? - Inserting a convert if these types don't match doesn't work because fir.convert doesn't know how to convert a hlfir.expr. Should this be added? Test case is from @vzakhari Differential Revision: https://reviews.llvm.org/D151202 | 3 年前 | |
[flang][hlfir] Fixed some finalization/deallocation issues. (#67047) This set of commits resolves some of the issues with elemental calls producing results that may require finalization, and also some memory leak issues due to the missing deallocation of allocatable components of the temporary buffers created by the bufferization pass. - [flang][runtime] Expose Finalize API for derived types. - [flang][hlfir] Add 'finalize' attribute for DestroyOp. - [flang][hlfir] Postpone result finalization for elemental calls. The results of elemental calls generated inside hlfir.elemental must not be finalized/destructed before they are copied into the resulting array. The finalization must be done on the array as a whole (e.g. there might be different scalar and array finalization routines). The finalization work is left to the hlfir.destroy corresponding to this hlfir.elemental. - [flang][hlfir] Tighten requirements on hlfir.end_associate operand. If component deallocation might be required for the operand of hlfir.end_associate, we have to be able to get the variable shape/params to create a descriptor for calling the runtime. This commit adds verification that we can do so. - [flang][hlfir] Lower argument clean-ups using valid hlfir.end_associate. The operand must be a Fortran entity, when allocatable component deallocation may be required. - [flang][hlfir] Properly clean-up temporary buffers in bufferization pass. This commit combines changes for proper finalization and component deallocation of the temporary buffers. The finalization part relates to hlfir.destroy operations with 'finalize' attribute. The component deallocation might be invoked for both hlfir.destroy and hlfir.end_associate, if the operand is of a derived type with allocatable component(s). The changes are mostly in one function, so I decided not to split them. - [flang][hlfir] Disable optimizations for hlfir.elemental requiring finalization. If hlfir.elemental is coupled with hlfir.destroy with 'finalize' attribute, the temporary array result of hlfir.elemental needs to be created for the purpose of finalization. We cannot do certain optimizations on such hlfir.elemental operations. I was not able to come up with a test for the OptimizedBufferization pass, but I put the check there as well. | 2 年前 | |
[flang] Use optimal shape for assign expansion as a loop. (#143050) During hlfir.assign inlining and ElementalAssignBufferization we can deduce the optimal shape from lhs and rhs shapes. It is probably better be done in a separate pass that propagates constant shapes, but I have not seen any benchmarks that would benefit from this yet. So consider this as a workaround for a bigger TODO issue. The ElementalAssignBufferization case is from 465.tonto, but I do not have performance results yet (I do not expect much). | 1 年前 | |
[flang][NFC] Characterize allocation based on MemAlloc effect instead of pattern matching (#166806) Flang alias analysis used to find allocation site by pattern matching allocation ops in mainly FIR dialect. This MR extends the characterization to instead characterize based on whether the result of an op has MemAlloc effect. | 8 个月前 | |
[flang][HLFIR] add skip_rebox option to hlfir.declare (#162305) hlfir.declare with a fir.box input always lead to a fir.rebox being created to ensure the lower bounds and attributes are set correctly in the local descriptor for the entity. This is really needed for hlfir.declare using fir.box function argument that do not come with any guarantees with regards to the lower bounds. Sometimes however, this fir.rebox just adds a lot of noise in the SSA chain, especially at the LLVM level and it is known that the input descriptor is already correct. I am making this patch in the context of OpenACC where I want to remap the variables inside the compute region, creating a fir.rebox on the way. This fir.rebox cannot be optimized away by FIR because of the OpenACC ops in the SSA chain. This patch adds a flag to indicate the the fir.box is known to have the correct lower bounds and attributes so that it can have a simpler code generation to FIR. | 9 个月前 | |
[flang] Do not produce result for void runtime call (#123155) Runtime function call to a void function are producing a ssa value because the FunctionType result is set to NoneType with is later translated to a empty struct. This is not an issue when going to LLVM IR but it breaks when lowering a gpu module to PTX. This patch update the RTModel to correctly set the FunctionType result type to nothing. This is one runtime call before this patch at the LLVM IR dialect step. %45 = llvm.call @_FortranAAssign(%arg0, %1, %44, %4) : (!llvm.ptr, !llvm.ptr, !llvm.ptr, i32) -> !llvm.struct<()> After the patch the call would be correctly formed llvm.call @_FortranAAssign(%arg0, %1, %44, %4) : (!llvm.ptr, !llvm.ptr, !llvm.ptr, i32) -> () Without the patch it would lead to error like: ptxas /tmp/mlir-cuda_device_mod-nvptx64-nvidia-cuda-sm_60-e804b6.ptx, line 10; error : Output parameter cannot be an incomplete array. ptxas /tmp/mlir-cuda_device_mod-nvptx64-nvidia-cuda-sm_60-e804b6.ptx, line 125; error : Call has wrong number of parameters The change is pretty much mechanical. | 1 年前 | |
[flang] add hlfir.matmul operation Add a HLFIR operation for the MATMUL transformational intrinsic, according to the design set out in flang/doc/HighLevelFIR.md Differential Revision: https://reviews.llvm.org/D144094 | 3 年前 | |
[flang][hlfir] add hlfir.matmul_transpose operation This operation will be used to transform MATMUL(TRANSPOSE(a), b). The transformation will go in the following stages: 1. Lowering to hlfir.transpose and hlfir.matmul 2. Canonicalise to hlfir.matmul_transpose 3. hlfir.matmul_transpose will be lowered to FIR as a new runtime library call Step 2 (and this operation) are included for consistency with the other hlfir intrinsic operations and to avoid mixing concerns in the intrinsic lowering pass. In step 3, a new runtime library call is used because this operation is most easily implemented in one go (the transposed indexing actually makes the indexing simpler than for a normal matrix multiplication). In the long run, it is intended that HLFIR will allow the same buffer to be shared between different runtime calls without temporary allocations, but in this specific case we can do even better than that with a dedicated implementation. This should speed up galgel from SPEC2000 (but this hadn't been tested yet). The optimization was implemented in Classic Flang. Reviewed By: vzakhari Differential Revision: https://reviews.llvm.org/D145957 | 3 年前 | |
[flang][NFC] use hlfir.declare first result when both results are raw pointers (#132261) Currently, the helpers to get fir::ExtendedValue out of hlfir::Entity use hlfir.declare second result ( #1) in most cases. This is because this result is the same as the input and matches what FIR was getting before lowering to HLFIR. But this creates odd situations when both hlfir.declare are raw pointers and either result ends-up being used in the IR depending on whether the code was generated by a helper using fir::ExtendedValue, or via "pure HLFIR" helpers using the first result. This will typically prevent simple CSE and easy identification that two operation (e.g load/store) are touching the exact same memory location without using alias analysis or "manual detection" (looking for common hlfir.declare defining op). Hence, when hlfir.declare results are both raw pointers, use #0 when producing fir::ExtendedValue. When #0 is a fir.box, keep using #1 because these are not the same. The only code change is in HLFIRTools.cpp and is pretty small, but there is a big test fallout of #1 to #0. | 1 年前 | |
| 2 年前 | ||
[flang][NFC] use hlfir.declare first result when both results are raw pointers (#132261) Currently, the helpers to get fir::ExtendedValue out of hlfir::Entity use hlfir.declare second result ( #1) in most cases. This is because this result is the same as the input and matches what FIR was getting before lowering to HLFIR. But this creates odd situations when both hlfir.declare are raw pointers and either result ends-up being used in the IR depending on whether the code was generated by a helper using fir::ExtendedValue, or via "pure HLFIR" helpers using the first result. This will typically prevent simple CSE and easy identification that two operation (e.g load/store) are touching the exact same memory location without using alias analysis or "manual detection" (looking for common hlfir.declare defining op). Hence, when hlfir.declare results are both raw pointers, use #0 when producing fir::ExtendedValue. When #0 is a fir.box, keep using #1 because these are not the same. The only code change is in HLFIRTools.cpp and is pretty small, but there is a big test fallout of #1 to #0. | 1 年前 | |
[flang][hlfir] Add hlfir.maxval intrinsic (#65705) Adds a new HLFIR operation for the MAXVAL intrinsic according to the design set out in flang/docs/HighLevelFIR.md. | 2 年前 | |
[mlir][vector] Fix attaching write effects on transfer_write's base (#142940) This fixes an issue with TransferWriteOp's implementation of the MemoryEffectOpInterface where the write effect was attached to the stored value rather than the base. This had the effect that when asking for the memory effects for the input memref buffer using getEffectsOnValue(...), the function would return no-effects (as the effect would have been attached to the stored value rather than the input buffer). | 1 年前 | |
[flang][NFC] use hlfir.declare first result when both results are raw pointers (#132261) Currently, the helpers to get fir::ExtendedValue out of hlfir::Entity use hlfir.declare second result ( #1) in most cases. This is because this result is the same as the input and matches what FIR was getting before lowering to HLFIR. But this creates odd situations when both hlfir.declare are raw pointers and either result ends-up being used in the IR depending on whether the code was generated by a helper using fir::ExtendedValue, or via "pure HLFIR" helpers using the first result. This will typically prevent simple CSE and easy identification that two operation (e.g load/store) are touching the exact same memory location without using alias analysis or "manual detection" (looking for common hlfir.declare defining op). Hence, when hlfir.declare results are both raw pointers, use #0 when producing fir::ExtendedValue. When #0 is a fir.box, keep using #1 because these are not the same. The only code change is in HLFIRTools.cpp and is pretty small, but there is a big test fallout of #1 to #0. | 1 年前 | |
[Flang] Add a HLFIR Minloc intrinsic (#74436) The adds a hlfir minloc intrinsic, similar to the minval intrinsic already added, to help in the lowering of minloc. The idea is to later add maxloc too, and from there add a simplification for producing minloc with inlined elemental and hopefully less temporaries. | 2 年前 | |
[flang][NFC] use hlfir.declare first result when both results are raw pointers (#132261) Currently, the helpers to get fir::ExtendedValue out of hlfir::Entity use hlfir.declare second result ( #1) in most cases. This is because this result is the same as the input and matches what FIR was getting before lowering to HLFIR. But this creates odd situations when both hlfir.declare are raw pointers and either result ends-up being used in the IR depending on whether the code was generated by a helper using fir::ExtendedValue, or via "pure HLFIR" helpers using the first result. This will typically prevent simple CSE and easy identification that two operation (e.g load/store) are touching the exact same memory location without using alias analysis or "manual detection" (looking for common hlfir.declare defining op). Hence, when hlfir.declare results are both raw pointers, use #0 when producing fir::ExtendedValue. When #0 is a fir.box, keep using #1 because these are not the same. The only code change is in HLFIRTools.cpp and is pretty small, but there is a big test fallout of #1 to #0. | 1 年前 | |
| 1 年前 | ||
[flang][hlfir] Add hlfir.minval intrinsic (#66306) Adds a new HLFIR operation for the MINVAL intrinsic according to the design set out in flang/docs/HighLevelFIR.md. | 2 年前 | |
[flang][NFC] use hlfir.declare first result when both results are raw pointers (#132261) Currently, the helpers to get fir::ExtendedValue out of hlfir::Entity use hlfir.declare second result ( #1) in most cases. This is because this result is the same as the input and matches what FIR was getting before lowering to HLFIR. But this creates odd situations when both hlfir.declare are raw pointers and either result ends-up being used in the IR depending on whether the code was generated by a helper using fir::ExtendedValue, or via "pure HLFIR" helpers using the first result. This will typically prevent simple CSE and easy identification that two operation (e.g load/store) are touching the exact same memory location without using alias analysis or "manual detection" (looking for common hlfir.declare defining op). Hence, when hlfir.declare results are both raw pointers, use #0 when producing fir::ExtendedValue. When #0 is a fir.box, keep using #1 because these are not the same. The only code change is in HLFIRTools.cpp and is pretty small, but there is a big test fallout of #1 to #0. | 1 年前 | |
[InstCombine] Canonicalize constant GEPs to i8 source element type (#68882) This patch canonicalizes getelementptr instructions with constant indices to use the i8 source element type. This makes it easier for optimizations to recognize that two GEPs are identical, because they don't need to see past many different ways to express the same offset. This is a first step towards https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699. This is limited to constant GEPs only for now, as they have a clear canonical form, while we're not yet sure how exactly to deal with variable indices. The test llvm/test/Transforms/PhaseOrdering/switch_with_geps.ll gives two representative examples of the kind of optimization improvement we expect from this change. In the first test SimplifyCFG can now realize that all switch branches are actually the same. In the second test it can convert it into simple arithmetic. These are representative of common optimization failures we see in Rust. Fixes https://github.com/llvm/llvm-project/issues/69841. | 2 年前 | |
[flang] add hlfir.noreassoc codegen Differential Revision: https://reviews.llvm.org/D139542 | 3 年前 | |
[flang] add hlfir.no_reassoc definition Same as fir.no_reassoc but accepts hlfir.expr type. It is needed because FIR operation can only produce FIR types, and I do not want to change that for now. Depends on D139519 Differential Revision: https://reviews.llvm.org/D139520 | 3 年前 | |
[flang] add hlfir.null to implement NULL() In HLFIR, the address of a Fortran entity in lowering must be defined by an operation that has the FortranVariableOpInterface (it is a sanity requirement to ensure that the mlir::Value propagated in certain places of lowering can be reasoned about). fir.zero_bits does not have this interface and it makes little sense to add it since it can "zero initialize" more types than just addresses. Creating an hlfir.declare for null addresses is a bit too much (what would be the name), and it would be noisy in the IR. Instead add a small hlfir.null operation whose codegen is simply a replacement by fir.zero_bits. It may also later help dealing with the NULL(MOLD) cases in a nicer way (the current lowering of this uses special handling it). Differential Revision: https://reviews.llvm.org/D141040 | 3 年前 | |
[flang] add hlfir.null to implement NULL() In HLFIR, the address of a Fortran entity in lowering must be defined by an operation that has the FortranVariableOpInterface (it is a sanity requirement to ensure that the mlir::Value propagated in certain places of lowering can be reasoned about). fir.zero_bits does not have this interface and it makes little sense to add it since it can "zero initialize" more types than just addresses. Creating an hlfir.declare for null addresses is a bit too much (what would be the name), and it would be noisy in the IR. Instead add a small hlfir.null operation whose codegen is simply a replacement by fir.zero_bits. It may also later help dealing with the NULL(MOLD) cases in a nicer way (the current lowering of this uses special handling it). Differential Revision: https://reviews.llvm.org/D141040 | 3 年前 | |
[flang] Improve disjoint/identical slices recognition in opt-bufferization. (#119780) The changes are needed to be able to optimize 'x(9,:)=SUM(x(1:8,:),DIM=1)' without a temporary array. This pattern exists in exchange2. The patch also fixes an existing problem in Flang with this test: program main integer :: a(10) = (/1,2,3,4,5,6,7,8,9,10/) integer :: expected(10) = (/1,10,9,8,7,6,5,4,3,2/) print *, 'INPUT: ', a print *, 'EXPECTED: ', expected call test(a, 10, 2, 10, 9) print *, 'RESULT: ', a contains subroutine test(a, size, x, y, z) integer :: x, y, z, size integer :: a(:) a(x:y:1) = a(z:x-1:-1) + 1 end subroutine test end program main | 1 年前 | |
[flang] Use optimal shape for assign expansion as a loop. (#143050) During hlfir.assign inlining and ElementalAssignBufferization we can deduce the optimal shape from lhs and rhs shapes. It is probably better be done in a separate pass that propagates constant shapes, but I have not seen any benchmarks that would benefit from this yet. So consider this as a workaround for a bigger TODO issue. The ElementalAssignBufferization case is from 465.tonto, but I do not have performance results yet (I do not expect much). | 1 年前 | |
[flang] Treat hlfir.associate as Allocate for FIR alias analysis. (#139004) Early HLFIR optimizations may experience problems with values produced by hlfir.associate. In most cases this is a unique local memory allocation, but it can also reuse some other hlfir.expr memory sometimes. It seems to be safe to assume unique allocation for trivial types, since we always allocate new memory for them. | 1 年前 | |
[flang][NFC] use hlfir.declare first result when both results are raw pointers (#132261) Currently, the helpers to get fir::ExtendedValue out of hlfir::Entity use hlfir.declare second result ( #1) in most cases. This is because this result is the same as the input and matches what FIR was getting before lowering to HLFIR. But this creates odd situations when both hlfir.declare are raw pointers and either result ends-up being used in the IR depending on whether the code was generated by a helper using fir::ExtendedValue, or via "pure HLFIR" helpers using the first result. This will typically prevent simple CSE and easy identification that two operation (e.g load/store) are touching the exact same memory location without using alias analysis or "manual detection" (looking for common hlfir.declare defining op). Hence, when hlfir.declare results are both raw pointers, use #0 when producing fir::ExtendedValue. When #0 is a fir.box, keep using #1 because these are not the same. The only code change is in HLFIRTools.cpp and is pretty small, but there is a big test fallout of #1 to #0. | 1 年前 | |
[flang][hlfir] Make alias analysis trace through box designators. (#67353) The changes are needed to get leslie3d same performance with HLFIR as with FIR lowering. The two module allocatable variables cannot alias, so the optimized bufferization should be able to elide the temporary and inline the assignment loop. | 2 年前 | |
[flang] Assume matching shapes in elemental assignment with non-realloc lhs. (#118552) The optimized bufferization pass cannot optimize very simple cases of elemental assignments, because of the suboptimal checks order. This patch relies on the fact that in a legal program the lhs and rhs of an assignment have matching shapes, when lhs is not an allocatable and rhs is a result of an elemental array operation. | 1 年前 | |
[flang] Improve designate/elemental indices match in opt-bufferization. (#121371) This pattern appears in tonto: rys1%w = rys1%w * ..., where component w is a pointer. Due to the computations transforming the elemental's one-based indices to the array indices, the indices match check did not pass in opt-bufferization. This patch recognizes this indices adjusting pattern, and returns the one-based indices for the designator. | 1 年前 | |
[flang] Skip opt-bufferization when memory effect does not have an associated value (#140781) Memory effects on the volatile memory resource may not be attached to a particular source, in which case the value of an effect will be null. This caused this test case to crash in the optimized bufferization pass's safety analysis because it assumes it can get the SSA value modified by the memory effect. This is because memory effects on the volatile resource indicate that the operation must not be reordered with respect to other volatile operations, but there is not a material ssa value that can be pointed to. This patch changes the safety checks such that memory effects which do not have associated values are not safe for optimized bufferization. | 1 年前 | |
[flang] Relax conflicts detection in ElementalAssignBufferization. (#143045) If there is a read-effect operation inside hlfir.elemental, there is no reason to block moving it to the assignment point unless there are write-effect operations between the elemental and the assignment. The previous code was disallowing the optimization even if there were only read-effect operations in between. This case is from 465.tonto, though this change does not improve performance at all. | 1 年前 | |
[flang] Extract hlfir.assign inlining from opt-bufferization. (#121544) Optimized bufferization can transform hlfir.assign into a loop nest doing element per element assignment, but it avoids doing so for RHS that is hlfir.expr. This is done to let ElementalAssignBufferization pattern to try to do a better job. This patch moves the hlfir.assign inlining after opt-bufferization, and enables it for hlfir.expr RHS. The hlfir.expr RHS cases are present in tonto, and this patch results in some nice improvements. Note that those cases are handled by other compilers also using array temporaries, so this patch seems to just get rid of the Assign runtime overhead/inefficiency. | 1 年前 | |
| 1 年前 | ||
[mlir][OpenMP][flang] make private variable allocation implicit in omp.private (#124019) The intention of this work is to give MLIR->LLVMIR conversion freedom to control how the private variable is allocated so that it can be allocated on the stack in ordinary cases or as part of a structure used to give closure context for tasks which might outlive the current stack frame. See RFC: https://discourse.llvm.org/t/rfc-openmp-supporting-delayed-task-execution-with-firstprivate-variables/83084 For example, a privatizer for an integer used to look like mlir omp.private {type = private} @x.privatizer : !fir.ref<i32> alloc { ^bb0(%arg0: !fir.ref<i32>): %0 = ... allocate proper memory for the private clone ... omp.yield(%0 : !fir.ref<i32>) } After this change, allocation become implicit in the operation: mlir omp.private {type = private} @x.privatizer : i32 For more complex types that require initialization after allocation, an init region can be used: mlir omp.private {type = private} @x.privatizer : !some.type init { ^bb0(%arg0: !some.pointer<!some.type>, %arg1: !some.pointer<!some.type>): // initialize %arg1, using %arg0 as a mold for allocations omp.yield(%arg1 : !some.pointer<!some.type>) } dealloc { ^bb0(%arg0: !some.pointer<!some.type>): ... deallocate memory allocated by the init region ... omp.yield } This patch lays the groundwork for delayed task execution but is not enough on its own. After this patch all gfortran tests which previously passed still pass. There are the following changes to the Fujitsu test suite: - 0380_0009 and 0435_0009 are fixed - 0688_0041 now fails at runtime. This patch is testing firstprivate variables with tasks. Previously we got lucky with the undefined behavior and won the race. After these changes we no longer get lucky. This patch lays the groundwork for a proper fix for this issue. In flang the lowering re-uses the existing lowering used for reduction init and dealloc regions. In flang, before this patch we hit a TODO with the same wording when generating the copy region for firstprivate polymorphic variables. After this patch the box-like fir.class is passed by reference into the copy region, leading to a different path that didn't hit that old TODO but the generated code still didn't work so I added a new TODO in DataSharingProcessor. | 1 年前 | |
[flang][debug] Track dummy argument positions explicitly. (#167489) CHARACTER dummy arguments were treated as local variables in debug info. This happened because our method to get the argument number was not robust. It relied on DeclareOp having a direct reference to arguments which was not the case for character arguments. This is fixed by storing source-level argument positions in DeclareOp. Fixes #112886 | 8 个月前 | |
[flang][hlfir] Add hlfir.parent_comp for leaf parent component references In Fortran, it is possible to refer to the "parent part" of a derived type as if it were a component: Fortran type t1 integer :: i end type type t2 integer :: j end type type(t2) :: a print *, a%t1%i ! "inner" parent component reference print *, a%t1 ! "leaf" parent component reference end Inner parent component references can be dropped on the floor in lowering: "a%t1%i" is equivalent to "a%i". Leaf parent component references, however, must be taken care of. For scalars, "a%t1" is a simple addressc ast to "t1", for arrays, however, this creates an array section that must be represented with a descriptor (fir.box). hlfir.designate could have been extended to deal with this, but I think it would make hlfir.designate too complex and hard to manipulate. This patch adds an hlfir.parent_comp op that represents and implements leaf parent component references. Differential Revision: https://reviews.llvm.org/D144946 | 3 年前 | |
[flang][hlfir] Add hlfir.parent_comp for leaf parent component references In Fortran, it is possible to refer to the "parent part" of a derived type as if it were a component: Fortran type t1 integer :: i end type type t2 integer :: j end type type(t2) :: a print *, a%t1%i ! "inner" parent component reference print *, a%t1 ! "leaf" parent component reference end Inner parent component references can be dropped on the floor in lowering: "a%t1%i" is equivalent to "a%i". Leaf parent component references, however, must be taken care of. For scalars, "a%t1" is a simple addressc ast to "t1", for arrays, however, this creates an array section that must be represented with a descriptor (fir.box). hlfir.designate could have been extended to deal with this, but I think it would make hlfir.designate too complex and hard to manipulate. This patch adds an hlfir.parent_comp op that represents and implements leaf parent component references. Differential Revision: https://reviews.llvm.org/D144946 | 3 年前 | |
[flang][NFC] use hlfir.declare first result when both results are raw pointers (#132261) Currently, the helpers to get fir::ExtendedValue out of hlfir::Entity use hlfir.declare second result ( #1) in most cases. This is because this result is the same as the input and matches what FIR was getting before lowering to HLFIR. But this creates odd situations when both hlfir.declare are raw pointers and either result ends-up being used in the IR depending on whether the code was generated by a helper using fir::ExtendedValue, or via "pure HLFIR" helpers using the first result. This will typically prevent simple CSE and easy identification that two operation (e.g load/store) are touching the exact same memory location without using alias analysis or "manual detection" (looking for common hlfir.declare defining op). Hence, when hlfir.declare results are both raw pointers, use #0 when producing fir::ExtendedValue. When #0 is a fir.box, keep using #1 because these are not the same. The only code change is in HLFIRTools.cpp and is pretty small, but there is a big test fallout of #1 to #0. | 1 年前 | |
[flang] Change return type of reduction intrinsics Comments in the recent patch https://reviews.llvm.org/D149964, mentioned that using hlfir_ExprType in cases where intrinsics return simple scalars adds unnecessary abstraction that isn't needed unless an array type is being used. This patch modifies the HLFIR operations for product, sum and any so that they only return a hlfir_ExprType when the result is an array, otherwise they will return just the simple scalar type. Differential Revision: https://reviews.llvm.org/D150877 | 3 年前 | |
[flang] Propagate contiguous attribute through HLFIR. (#138797) This change allows marking more designators producing an opaque box with 'contiguous' attribute, e.g. like in test1 case in flang/test/HLFIR/propagate-contiguous-attribute.fir. This would make isSimplyContiguous() return true for such designators allowing merging hlfir.eval_in_mem with hlfir.assign where the LHS is a contiguous array section. Depends on #139003 | 1 年前 | |
[flang][hlfir] Add hlfir.region_assign and its hlfir.yield terminator hlfir.region_assign is a Region based version of hlfir.assign: the right-hand side and left-hand-side are evaluated in their own region, and an optional region can be added to implement user defined assignment. This will be used for: - assignments inside where and forall - user defined assignments - assignments to vector subscripted entities. Rational: Forall and Where lowering requires solving an expression/assignment evaluation scheduling problem based on data dependencies between the variables being assigned and the one used in the expressions. Keeping left-hand side and right-hand side in their own region will make it really easy to analyse the dependency and move around the expression evaluation as a whole. Operation DAGs are hard to scissor out when the LHS and RHS evaluation are lowered in the same block. The pass dealing with further forall/where lowering in HLFIR will need to succeed. It is not acceptable for them to fail splitting the RHS/LHS evaluation code. Keeping them in independent block is an approach that cannot fail. For user defined assignments, having a region allows implementing all the call details in lowering, and even to allow inlining of the user assignment, before it is decided if a temporary for the LHS or RHS is required or not. The operation description mention "hlfir.elemental_addr" (operation that will be used for vector subscripted LHS) and "ordered assignment trees" (concept/inetrface that will be used to represent forall/where structure in HLFIR). These will be pushed in follow-up patch, but I do not want t scissor out the descriptions. Differential Revision: https://reviews.llvm.org/D149442 | 3 年前 | |
[flang][hlfir] ensure hlfir.declare result box attributes are consistent (#143137) Prevent hlfir.declare output to be fir.box/class values with the heap/pointer attribute to ensure the runtime descriptor attributes are in line with the Fortran attributes for the entities being declared (only fir.ref<box/class> can be ALLOCATABLE/POINTERS). This fixes a bug where an associated entity inside a SELECT TYPE was being unexpectedly reallocated inside assign runtime because the selector was allocatable and this attribute was not properly removed when creating the descriptor for the associated entity (that does not inherit the ALLOCATABLE/POINTER attribute according to Fortran 2023 section 11.1.3.3). | 1 年前 | |
[flang] Added hlfir.reshape definition/lowering/codegen. (#124226) Lower Fortran RESHAPE intrinsic into hlfir.reshape, and then lower hlfir.reshape into a runtime call. A later patch will add hlfir.reshape inlining as hlfir.elemental. | 1 年前 | |
[flang][hlfir] Special handling for temporary LHS in AssignOp. When AssignOp is used with LHS that is a compiler generated temporary special care must be taken to initialize the temporary and avoid finalizations of its components. This change-set adds optional temporary_lhs attribute for AssignOp to convey this information to HLFIR-to-FIR conversion pass. Currently, this results in calling AssignTemporary runtime for doing the assignment. Reviewed By: jeanPerier, tblah Differential Revision: https://reviews.llvm.org/D152482 | 3 年前 | |
[flang] Add hlfir.set_length operation This will implement evaluate::SetLength where the length of a character entity is changed (with trimming and padding). Differential Revision: https://reviews.llvm.org/D140219 | 3 年前 | |
[flang][hlfir] lower hlfir.shape_of If possible the shape is gotten from the bufferization of the expr argument. The simple cases should already have been resolved during lowering. This is mostly intended for cases where shape information is added in between lowering and the end of bufferization (for example transformational intrinsics with assumed shape arguments). Depends on: D146832 Differential Revision: https://reviews.llvm.org/D146833 | 3 年前 | |
[flang] Simple folding for hlfir.shape_of. (#119649) This folding makes sure there are no hlfir.shape_of users of hlfir.elemental - this may enable more InlineElementals matches, because it is looking for exactly two uses of an hlfir.elemental. | 1 年前 | |
Reland [flang] Generalized simplification of HLFIR reduction ops. (#136071) (#136246) This change generalizes SumAsElemental inlining in SimplifyHLFIRIntrinsics pass so that it can be applied to ALL, ANY, COUNT, MAXLOC, MAXVAL, MINLOC, MINVAL, SUM. This change makes the special handling of the reduction operations in OptimizedBufferization redundant: once HLFIR operations are inlined, the hlfir.elemental inlining should do the rest of the job. | 1 年前 | |
Reland [flang] Generalized simplification of HLFIR reduction ops. (#136071) (#136246) This change generalizes SumAsElemental inlining in SimplifyHLFIRIntrinsics pass so that it can be applied to ALL, ANY, COUNT, MAXLOC, MAXVAL, MINLOC, MINVAL, SUM. This change makes the special handling of the reduction operations in OptimizedBufferization redundant: once HLFIR operations are inlined, the hlfir.elemental inlining should do the rest of the job. | 1 年前 | |
[flang] Lower hlfir.cmpchar into inline implementation in simplify-hlfir-intrinsics (#155461) | 11 个月前 | |
Reland [flang] Generalized simplification of HLFIR reduction ops. (#136071) (#136246) This change generalizes SumAsElemental inlining in SimplifyHLFIRIntrinsics pass so that it can be applied to ALL, ANY, COUNT, MAXLOC, MAXVAL, MINLOC, MINVAL, SUM. This change makes the special handling of the reduction operations in OptimizedBufferization redundant: once HLFIR operations are inlined, the hlfir.elemental inlining should do the rest of the job. | 1 年前 | |
[flang] Inline hlfir.eoshift during HLFIR intrinsics simplication. (#153108) This patch generalizes the code for hlfir.cshift to be applicable for hlfir.eoshift. The major difference is the selection of the boundary value that might be statically/dynamically absent, in which case the default scalar value has to be used. The scalar value of the boundary is always computed before the hlfir.elemental or the assignment loop. Contrary to hlfir.cshift simplication, the SHIFT value is not normalized, because the original value (and its sign) participate in the EOSHIFT index computation for addressing the input array and selecting which elements of the results are assigned from the boundary operand. | 11 个月前 | |
Reland "[flang] Inline hlfir.dot_product. (#123143)" (#123385) This reverts commit afc43a7b626ae07f56e6534320e0b46d26070750. +Fixed declaration of hlfir::genExtentsVector(). Some good results for induct2, where dot_product is applied to a vector of unknow size and a known 3-element vector: the inlining ends up generating a 3-iteration loop, which is then fully unrolled. With late FIR simplification it is not happening even when the simplified intrinsics implementation is inlined by LLVM (because the loop bounds are not known). This change just follows the current approach to expose the loops for later worksharing application. | 1 年前 | |
Reapply "[flang] Lower EOSHIFT into hlfir.eoshift." (#153907) (#154241) This reverts commit 5178aeff7b96e86b066f8407b9d9732ec660dd2e. In addition: * Scalar constant UNSIGNED BOUNDARY is explicitly casted to the result type so that the generated hlfir.eoshift operation is valid. The lowering produces signless constants by default. It might be a bigger issue in lowering, so I just want to "fix" it for EOSHIFT in this patch. * Since we have to create unsigned integer constant during HLFIR inlining, I added code in createIntegerConstant to make it possible. | 11 个月前 | |
[flang] Simplify hlfir.index in a few limited cases. (#161558) Primarily targeted simplification case of substring being a singleton by inlining a search loop (with an exception where runtime function performs better). Few trivial simplifications also covered. This is a reapply of #157883 with additional fix to avoid generation of new ops during analysis that mess up greedy rewriter if we end up bailing out without any simplification but just leaving few stranded new ops. For technical reasons this patch comes as a new PR. | 10 个月前 | |
[flang] Optimize redundant array repacking. (#147881) This patch allows optimizing redundant array repacking, when the source array is statically known to be contiguous. This is part of the implementation plan for the array repacking feature, though, it does not affect any real life use case as long as FIR inlining is not a thing. I experimented with simple cases of FIR inling using -inline-all, and I recorded these cases in optimize-array-repacking.fir tests. | 1 年前 | |
[flang] Fetch the initial reduction value from the input array. (#136790) Instead of using loop-carried IsFirst predicate, we can fetch the initial reduction values for MIN/MAX LOC/VAL reductions from the array itself. This results in a little bit cleaner loop nests, especially, generated for total reductions. Otherwise, LLVM is able to peel the first iteration of the innermost loop, but the surroudings of the peeled code are executed multiple times withing the outer loop(s). This patch does the manual peeling, which only works for non-masked reductions where the input array is not empty. | 1 年前 | |
[flang] Fetch the initial reduction value from the input array. (#136790) Instead of using loop-carried IsFirst predicate, we can fetch the initial reduction values for MIN/MAX LOC/VAL reductions from the array itself. This results in a little bit cleaner loop nests, especially, generated for total reductions. Otherwise, LLVM is able to peel the first iteration of the innermost loop, but the surroudings of the peeled code are executed multiple times withing the outer loop(s). This patch does the manual peeling, which only works for non-masked reductions where the input array is not empty. | 1 年前 | |
[flang] Fetch the initial reduction value from the input array. (#136790) Instead of using loop-carried IsFirst predicate, we can fetch the initial reduction values for MIN/MAX LOC/VAL reductions from the array itself. This results in a little bit cleaner loop nests, especially, generated for total reductions. Otherwise, LLVM is able to peel the first iteration of the innermost loop, but the surroudings of the peeled code are executed multiple times withing the outer loop(s). This patch does the manual peeling, which only works for non-masked reductions where the input array is not empty. | 1 年前 | |
[flang] Fetch the initial reduction value from the input array. (#136790) Instead of using loop-carried IsFirst predicate, we can fetch the initial reduction values for MIN/MAX LOC/VAL reductions from the array itself. This results in a little bit cleaner loop nests, especially, generated for total reductions. Otherwise, LLVM is able to peel the first iteration of the innermost loop, but the surroudings of the peeled code are executed multiple times withing the outer loop(s). This patch does the manual peeling, which only works for non-masked reductions where the input array is not empty. | 1 年前 | |
[flang] Inline hlfir.reshape as hlfir.elemental. (#124683) This patch inlines hlfir.reshape for simple cases, such as when there is no ORDER argument; and when PAD is present, only the trivial types are handled. | 1 年前 | |
[flang][NFC] Removed unneeded engineering option. (#122305) | 1 年前 | |
[flang] Turn SimplifyHLFIRIntrinsics into a greedy rewriter. (#119946) This is almost an NFC, except that folding changed ordering of some operations. | 1 年前 | |
[flang][NFC] use hlfir.declare first result when both results are raw pointers (#132261) Currently, the helpers to get fir::ExtendedValue out of hlfir::Entity use hlfir.declare second result ( #1) in most cases. This is because this result is the same as the input and matches what FIR was getting before lowering to HLFIR. But this creates odd situations when both hlfir.declare are raw pointers and either result ends-up being used in the IR depending on whether the code was generated by a helper using fir::ExtendedValue, or via "pure HLFIR" helpers using the first result. This will typically prevent simple CSE and easy identification that two operation (e.g load/store) are touching the exact same memory location without using alias analysis or "manual detection" (looking for common hlfir.declare defining op). Hence, when hlfir.declare results are both raw pointers, use #0 when producing fir::ExtendedValue. When #0 is a fir.box, keep using #1 because these are not the same. The only code change is in HLFIRTools.cpp and is pretty small, but there is a big test fallout of #1 to #0. | 1 年前 | |
[flang] Change return type of reduction intrinsics Comments in the recent patch https://reviews.llvm.org/D149964, mentioned that using hlfir_ExprType in cases where intrinsics return simple scalars adds unnecessary abstraction that isn't needed unless an array type is being used. This patch modifies the HLFIR operations for product, sum and any so that they only return a hlfir_ExprType when the result is an array, otherwise they will return just the simple scalar type. Differential Revision: https://reviews.llvm.org/D150877 | 3 年前 | |
[flang][NFC] use hlfir.declare first result when both results are raw pointers (#132261) Currently, the helpers to get fir::ExtendedValue out of hlfir::Entity use hlfir.declare second result ( #1) in most cases. This is because this result is the same as the input and matches what FIR was getting before lowering to HLFIR. But this creates odd situations when both hlfir.declare are raw pointers and either result ends-up being used in the IR depending on whether the code was generated by a helper using fir::ExtendedValue, or via "pure HLFIR" helpers using the first result. This will typically prevent simple CSE and easy identification that two operation (e.g load/store) are touching the exact same memory location without using alias analysis or "manual detection" (looking for common hlfir.declare defining op). Hence, when hlfir.declare results are both raw pointers, use #0 when producing fir::ExtendedValue. When #0 is a fir.box, keep using #1 because these are not the same. The only code change is in HLFIRTools.cpp and is pretty small, but there is a big test fallout of #1 to #0. | 1 年前 | |
[flang] add hlfir.transpose operation Add a HLFIR operation for the TRANSPOSE transformational intrinsic, according to the design set out in flang/doc/HighLevelFIR.md Differential Revision: https://reviews.llvm.org/D144880 | 3 年前 | |
[flang] Add hlfir.char_trim operation (#156064) Fortran character trim is currently lowered directly into a runtime call, which makes it more complex to simplify expressions using it. With this patch trim is first lowered into an hlfir.char_trim operation, that is only later transformed into a runtime call. This makes it easier to remove unnecessary calls to trim, as proposed in #154593. | 10 个月前 | |
[flang] Hide strict volatility checks behind flag (#138183) Enabling volatility lowering by default revealed some issues in lowering and op verification. For example, given volatile variable of a nested type, accessing structure members of a structure member would result in a volatility mismatch when the inner structure member is designated (and thus a verification error at compile time). In other cases, I found correct codegen when the checks were disabled, also related to allocatable types and how we handle volatile references of boxes. This hides the strict verification of fir and hlfir ops behind a flag so I can iteratively improve lowering of volatile variables without causing compile-time failures, keeping the strict verification on when running tests. | 1 年前 | |
[flang] Hide strict volatility checks behind flag (#138183) Enabling volatility lowering by default revealed some issues in lowering and op verification. For example, given volatile variable of a nested type, accessing structure members of a structure member would result in a volatility mismatch when the inner structure member is designated (and thus a verification error at compile time). In other cases, I found correct codegen when the checks were disabled, also related to allocatable types and how we handle volatile references of boxes. This hides the strict verification of fir and hlfir ops behind a flag so I can iteratively improve lowering of volatile variables without causing compile-time failures, keeping the strict verification on when running tests. | 1 年前 | |
[flang] Hide strict volatility checks behind flag (#138183) Enabling volatility lowering by default revealed some issues in lowering and op verification. For example, given volatile variable of a nested type, accessing structure members of a structure member would result in a volatility mismatch when the inner structure member is designated (and thus a verification error at compile time). In other cases, I found correct codegen when the checks were disabled, also related to allocatable types and how we handle volatile references of boxes. This hides the strict verification of fir and hlfir ops behind a flag so I can iteratively improve lowering of volatile variables without causing compile-time failures, keeping the strict verification on when running tests. | 1 年前 | |
[flang] Hide strict volatility checks behind flag (#138183) Enabling volatility lowering by default revealed some issues in lowering and op verification. For example, given volatile variable of a nested type, accessing structure members of a structure member would result in a volatility mismatch when the inner structure member is designated (and thus a verification error at compile time). In other cases, I found correct codegen when the checks were disabled, also related to allocatable types and how we handle volatile references of boxes. This hides the strict verification of fir and hlfir ops behind a flag so I can iteratively improve lowering of volatile variables without causing compile-time failures, keeping the strict verification on when running tests. | 1 年前 | |
[flang] Hide strict volatility checks behind flag (#138183) Enabling volatility lowering by default revealed some issues in lowering and op verification. For example, given volatile variable of a nested type, accessing structure members of a structure member would result in a volatility mismatch when the inner structure member is designated (and thus a verification error at compile time). In other cases, I found correct codegen when the checks were disabled, also related to allocatable types and how we handle volatile references of boxes. This hides the strict verification of fir and hlfir ops behind a flag so I can iteratively improve lowering of volatile variables without causing compile-time failures, keeping the strict verification on when running tests. | 1 年前 | |
[flang][hlfir] Add assignment mask operations Add hlfir.forall_mask, hlfir.where, and hlfir.elsewhere operations that are operations that holds (optionally for hlfir.elsewhere) the evaluation of a logical mask that controls the evaluation of nested operations. They allow representing Fortran forall control mask, as well as where and eslewhere statements/constructs. They use the OrderedAssignmentTreeOpInterface since they can all be used inside Forall and their masks should be fully evaluated for all the index-value set induced by parent Forall before any of the nested operations in their body is evaluated. I initially tried making them into a single operation with some attributes to make a difference, but I felt this made the verifier/parser/printer and usages messier/tricky compared to making three distinct operations that represent the three Fortran feature in a vanilla way. Differential Revision: https://reviews.llvm.org/D149754 | 3 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 8 个月前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 11 个月前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 11 个月前 | ||
| 1 年前 | ||
| 11 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 11 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 10 个月前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 11 个月前 | ||
| 1 年前 | ||
| 11 个月前 | ||
| 1 年前 | ||
| 11 个月前 | ||
| 10 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 10 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 |