| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[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] support optional args for intrinsic ops This also adds support for allocatable non-optional arguments. Of the transformational intrinsics which currently have their own hlfir operations, all of the dynamically optional arguments are lowered as boxes, so that is all that is implemented for now. One alternative approach would have been to deal with the dynamically optional arguments when lowering to FIR runtime calls. I decided not to do this so that any passes working on the intrinsic operations would not have to know about and handle the dynamically optional arguments. Depends on D154235 Differential Revision: https://reviews.llvm.org/D154236 | 3 年前 | |
[flang][hlfir] Separate -emit-fir and -emit-hlfir for bbc In review for https://reviews.llvm.org/D146278, @vzakhari asked to separate -emit-fir and -emit-hlfir. This will allow FIR to be easily outputted after the HLFIR passes have been run. The new semantics are as follows: | Action | -hlfir? | Result | | =========== | ======= | =============================== | | -emit-hlfir | N | Outputs HLFIR | | -emit-hlfir | Y | Outputs HLFIR | | -emit-fir | N | Outputs FIR, using old lowering | | -emit-fir | Y | Outputs FIR, lowering via HLFIR | This is tested in flang/test/HLFIR/hlfir-flags.f90 Depends on: D151088 Differential Revision: https://reviews.llvm.org/D151108 | 3 年前 | |
[flang] simplify pointer assignments (#168732) Pointer assignment lowering was done in different ways depending on contexts and types, sometimes still using runtime calls when this is not needed and the complexity of doing this inline is very limited (the pointer and target descriptors were already prepared inline, the runtime is just doing the descriptor assignment and ensuring the pointer descriptor keep its pointer flag). Slightly extent the inline version that was used for Forall and use it for all cases. When lowering without HLFIR is removed, this will allow removing more code. | 8 个月前 | |
[flang][hlfir] Separate -emit-fir and -emit-hlfir for bbc In review for https://reviews.llvm.org/D146278, @vzakhari asked to separate -emit-fir and -emit-hlfir. This will allow FIR to be easily outputted after the HLFIR passes have been run. The new semantics are as follows: | Action | -hlfir? | Result | | =========== | ======= | =============================== | | -emit-hlfir | N | Outputs HLFIR | | -emit-hlfir | Y | Outputs HLFIR | | -emit-fir | N | Outputs FIR, using old lowering | | -emit-fir | Y | Outputs FIR, lowering via HLFIR | This is tested in flang/test/HLFIR/hlfir-flags.f90 Depends on: D151088 Differential Revision: https://reviews.llvm.org/D151108 | 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][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][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] support optional args for intrinsic ops This also adds support for allocatable non-optional arguments. Of the transformational intrinsics which currently have their own hlfir operations, all of the dynamically optional arguments are lowered as boxes, so that is all that is implemented for now. One alternative approach would have been to deal with the dynamically optional arguments when lowering to FIR runtime calls. I decided not to do this so that any passes working on the intrinsic operations would not have to know about and handle the dynamically optional arguments. Depends on D154235 Differential Revision: https://reviews.llvm.org/D154236 | 3 年前 | |
[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] 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][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] 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] 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] Make adapt.valuebyref attribute work again (#73658) This got "lost" in the HLFIR transformation. This patch applies the old attribute to the AssociateOp that needs it, and forwards it to the AllocaOp that is generated when lowering to FIR. | 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][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][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] Set assumed-size last extent to -1 (#79156) Currently lowering sets the extents of assumed-size array to "undef" which was OK as long as the value was not expected to be read. But when interfacing with the runtime and when passing assumed-size to assumed-rank, this last extent may be read and must be -1 as specified in the BIND(C) case in 18.5.3 point 5. Set this value to -1, and update all the lowering code that was looking for an undef defining op to identify assumed-size: much safer to propagate and use semantic info here, the previous check actually did not work if the array was used in an internal procedure (defining op not visible anymore). @clementval and @agozillon, I left assumed-size extent to zero in the acc/omp bounds op as it was, please double check that is what you want (I can imagine -1 may create troubles here, and 0 makes some sense as it would lead to no data transfer). This also allows removing special cases in UBOUND/LBOUND lowering. Also disable allocation of cray pointee. This was never intended and would now lead to crashes with the -1 value for assumed-size cray pointee. | 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] Lower BIND(C) assumed length to CFI descriptor (#65950) Outside of BIND(C), assumed length character scalar and explicit shape are passed by address + an extra length argument (fir.boxchar in FIR). The standard mandates that they be passed via CFI descriptor in BIND(C) interface (fir.box in FIR). This patch fix the handling for this case. | 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] Lower BIND(C) module variables (#78279) Lower initialized BIND(C) module variable as regular module variable, except that the fir.global symbol name is the binding label. For uninitialized variables, add the common linkage so that C code may define the variables. The standard does not provide a way to indicate that a variable is defined in C, but there are use cases. Beware that if the module file compiled object is added to a shared library, the variable will become a regular global definition and may override the C variable depending on the linking order. | 2 年前 | |
[flang] Lower special bind(c) cases without binding labels (#65758) 1. Deal with BIND(C,NAME="") BIND(C,NAME="") is different from BIND(C). The latter implies that there us a binding label which is the Fortran symbol name (no Fortran mangling must be added like underscores). The former implies there is no binding label (the name in the object file must be the same as if it there was no BIND(C) attribute at all). This is correctly implemented in the front-end, but lowering mistakenly overrode this in the code dealing with the case where BIND(C) is inherited from a procedure interface. Handling of this last case is moved into name resolution. 2. Deal with BIND(C) internal procedure Also according to 18.10.2, BIND(C) does not give a p prevent name resolution from adding a label to them, otherwise, bindc_internal_proc.f90 was not going through semantics (bogus error about conflicting global names). Nothing TODO in lowering other than removing the TODO. | 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] Lower special bind(c) cases without binding labels (#65758) 1. Deal with BIND(C,NAME="") BIND(C,NAME="") is different from BIND(C). The latter implies that there us a binding label which is the Fortran symbol name (no Fortran mangling must be added like underscores). The former implies there is no binding label (the name in the object file must be the same as if it there was no BIND(C) attribute at all). This is correctly implemented in the front-end, but lowering mistakenly overrode this in the code dealing with the case where BIND(C) is inherited from a procedure interface. Handling of this last case is moved into name resolution. 2. Deal with BIND(C) internal procedure Also according to 18.10.2, BIND(C) does not give a p prevent name resolution from adding a label to them, otherwise, bindc_internal_proc.f90 was not going through semantics (bogus error about conflicting global names). Nothing TODO in lowering other than removing the TODO. | 2 年前 | |
[flang] Give internal linkage to internal procedures (#81929) Internal procedures cannot be called directly from outside the host procedure, so there is no point giving them external linkage. The only reason flang did is because it is the default in MLIR. Giving external linkage to them: - prevents deleting them when not used/inlined by LLVM - causes bugs with shared libraries (at least on linux x86-64) because the call to the internal function could lead to a dynamic loader call that would overwrite r10 register (the static chain pointer) due to system calls and did not restore (it seems it does not expect r10 to be used for PLT calls). This patch gives internal linkage to internal procedures: Note: the llvm.linkage attribute name cannot be obtained via a getLinkageAttrName since it is not the same name as the one used in the LLVM dialect. It is just a placeholder defined in mlir/lib/Conversion/FuncToLLVM/FuncToLLVM.cpp until the func dialect gets a real linkage model. So simply avoid hard coding it too many times in lowering. | 2 年前 | |
[flang] add fir.proc_attrs attributes to func.func (#110002) BIND(C) ABI need care in the TargetRewrite pass. currently, we are not able to accurately identify fun.func that are BIND(C) in FIR (the fir.bindc_name is used in other contexts, like for program names). This patch adds the fir.proc_attrs to func.func just like it was done for calls recently. This replace the previous named attribute for PURE/ELEMENTAL/RECURSIVE (note that RECURSIVE is changed to NON_RECURSIVE, which brings more data since RECURSIVE is the default for procedures that do not have explicit RECURSIVE/NON_RECUSRIVE attributes). | 1 年前 | |
[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 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] Postpone hlfir.end_associate generation for calls. (#138786) If we generate hlfir.end_associate at the end of the statement, we get easier optimizable HLFIR, because there are no compiler generated operations with side-effects in between the call and the consumers. This allows more hlfir.eval_in_mem to reuse the LHS instead of allocating temporary buffer. I do not think the same can be done for hlfir.copy_out always, e.g.: subroutine test2(x) interface function array_func2(x,y) real:: x(*), array_func2(10), y end function array_func2 end interface real :: x(:) x = array_func2(x, 1.0) end subroutine test2 If we postpone the copy-out until after the assignment, then the result may be wrong. | 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][NFC] turn fir.call is_bind_c into enum for procedure flags (#105691) First patch to fix a BIND(C) ABI issue (https://github.com/llvm/llvm-project/issues/102113). I need to keep track of BIND(C) in more locations (fir.dispatch and func.func operations), and I need to fix a few passes that are dropping the attribute on the floor. Since I expect more procedure attributes that cannot be reflected in mlir::FunctionType will be needed for ABI, optimizations, or debug info, this NFC patch adds a new enum attribute to keep track of procedure attributes in the IR. This patch is not updating lowering to lower more attributes, this will be done in a separate patch to keep the test changes low here. Adding the attribute on fir.dispatch and func.func will also be done in separate patches. | 1 年前 | |
[flang] Enable polymorphic lowering by default (#83285) Polymorphic entity lowering status is good. The main remaining TODO is to allow lowering of vector subscripted polymorphic entity, but this does not deserve blocking all application using polymorphism. Remove experimental option and enable lowering of polymorphic entity by default. | 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][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] fix sequence association of polymorphic actual arguments (#99294) When passing a polymorphic actual array argument to an non polymorphic explicit or assumed shape argument, copy-in/copy-out may be required and should be made according to the dummy dynamic type. The code that was creating the descriptor to drive this copy-in/out was not handling properly the case where the dummy and actual rank do not match (possible according to sequence association rules), it tried to make the copy-in/out according to the dummy argument shape (which we may not even know if the dummy is assumed-size). Fix this by using the actual shape when creating this new descriptor with the dummy argument dynamic type. | 2 年前 | |
[flang] Lowering changes for assigning dummy_scope to hlfir.declare. (#90989) The lowering produces fir.dummy_scope operation if the current function has dummy arguments. Each hlfir.declare generated for a dummy argument is then using the result of fir.dummy_scope as its dummy_scope operand. This is only done for HLFIR. I was not able to find a reliable way to identify dummy symbols in genDeclareSymbol, so I added a set of registered dummy symbols that is alive during the variables instantiation for the current function. The set is initialized during the mapping of the dummy argument symbols to their MLIR values. It is reset right after all variables are instantiated - this is done to avoid generating hlfir.declare operations with dummy_scope for the clones of the dummy symbols (e.g. this happens with OpenMP privatization). If this can be done in a cleaner way, please advise. | 2 年前 | |
[flang][NFC] Strip trailing whitespace from tests (3 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] Use BIND name, if any, when consolidating common blocks (#65613) This patch changes how common blocks are aggregated and named in lowering in order to: * fix one obvious issue where BIND(C) and non BIND(C) with the same Fortran name were "merged" * go further and deal with a derivative where the BIND(C) C name matches the assembly name of a Fortran common block. This is a bit unspecified IMHO, but gfortran, ifort, and nvfortran "merge" the common block without complaints as a linker would have done. This required getting rid of all the common block mangling early in FIR (\_QC) instead of leaving that to the phase that emits LLVM from FIR because BIND(C) common blocks did not have mangled names. Care has to be taken to deal with the underscoring option of flang-new. See added flang/test/Lower/HLFIR/common-block-bindc-conflicts.f90 for an illustration. | 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][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] Separate -emit-fir and -emit-hlfir for bbc In review for https://reviews.llvm.org/D146278, @vzakhari asked to separate -emit-fir and -emit-hlfir. This will allow FIR to be easily outputted after the HLFIR passes have been run. The new semantics are as follows: | Action | -hlfir? | Result | | =========== | ======= | =============================== | | -emit-hlfir | N | Outputs HLFIR | | -emit-hlfir | Y | Outputs HLFIR | | -emit-fir | N | Outputs FIR, using old lowering | | -emit-fir | Y | Outputs FIR, lowering via HLFIR | This is tested in flang/test/HLFIR/hlfir-flags.f90 Depends on: D151088 Differential Revision: https://reviews.llvm.org/D151108 | 3 年前 | |
[flang] Change uniqueCGIdent separator from . to X (#71338) Change the separator in the uniqueCGIdent method to X. This change is required to enable OpenMP offloading for the NVPTX target, as dots are not valid identifiers in PTX and uniqueCGIdent is used to mangle some literals. Follow up patches will change the remainder of . appearances in names to X and add support for the NVPTX target. | 2 年前 | |
[flang][hlfir] Lower parent component in constant structure constructors (#71421) Simply remove TODO. Since parent components are now fields of the extended types fir.type<> in HLFIR, there is nothing specific to do to deal with the appearance of a parent component value in a structure constructor value that must be turned into a fir.global initial value: it can simply be inserted as a normal field value. | 2 年前 | |
[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] 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][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] Remove kind from CountOp (#75466) The kind is already represented in the return type of the operation. Like we did for minloc, this removes the kind parameter from CountOp. | 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][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] Separate -emit-fir and -emit-hlfir for bbc In review for https://reviews.llvm.org/D146278, @vzakhari asked to separate -emit-fir and -emit-hlfir. This will allow FIR to be easily outputted after the HLFIR passes have been run. The new semantics are as follows: | Action | -hlfir? | Result | | =========== | ======= | =============================== | | -emit-hlfir | N | Outputs HLFIR | | -emit-hlfir | Y | Outputs HLFIR | | -emit-fir | N | Outputs FIR, using old lowering | | -emit-fir | Y | Outputs FIR, lowering via HLFIR | This is tested in flang/test/HLFIR/hlfir-flags.f90 Depends on: D151088 Differential Revision: https://reviews.llvm.org/D151108 | 3 年前 | |
[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] Enable polymorphic lowering by default (#83285) Polymorphic entity lowering status is good. The main remaining TODO is to allow lowering of vector subscripted polymorphic entity, but this does not deserve blocking all application using polymorphism. Remove experimental option and enable lowering of polymorphic entity by default. | 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][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] Separate -emit-fir and -emit-hlfir for bbc In review for https://reviews.llvm.org/D146278, @vzakhari asked to separate -emit-fir and -emit-hlfir. This will allow FIR to be easily outputted after the HLFIR passes have been run. The new semantics are as follows: | Action | -hlfir? | Result | | =========== | ======= | =============================== | | -emit-hlfir | N | Outputs HLFIR | | -emit-hlfir | Y | Outputs HLFIR | | -emit-fir | N | Outputs FIR, using old lowering | | -emit-fir | Y | Outputs FIR, lowering via HLFIR | This is tested in flang/test/HLFIR/hlfir-flags.f90 Depends on: D151088 Differential Revision: https://reviews.llvm.org/D151108 | 3 年前 | |
| 10 个月前 | ||
[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][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] 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] Generate math.acos op for non-precise acos intrinsic calls (#123641) This patch changes the codgegn for non-precise acos calls to generate math.acos ops. This wasn't done before because the math dialect did not have a acos operation at the time. | 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] Enable polymorphic lowering by default (#83285) Polymorphic entity lowering status is good. The main remaining TODO is to allow lowering of vector subscripted polymorphic entity, but this does not deserve blocking all application using polymorphism. Remove experimental option and enable lowering of polymorphic entity by default. | 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][lowering] delay stack save/restor emission in elemental calls (#109142) stack save/restore emitted for character elemental function result allocation inside hlfir.elemental in lowering created memory bugs because result memory is actually still used after the stack restore when lowering the elemental into a loop where the result element is copied into the array result storage. Instead of adding special handling for stack save/restore in lowering, just avoid emitting those since the stack reclaim pass is able to emit them in the generated loop. Not having those stack save/restore will also help optimizations that want to elide the temporary allocation for the element result when that is possible. | 1 年前 | |
[flang] Postpone hlfir.end_associate generation for calls. (#138786) If we generate hlfir.end_associate at the end of the statement, we get easier optimizable HLFIR, because there are no compiler generated operations with side-effects in between the call and the consumers. This allows more hlfir.eval_in_mem to reuse the LHS instead of allocating temporary buffer. I do not think the same can be done for hlfir.copy_out always, e.g.: subroutine test2(x) interface function array_func2(x,y) real:: x(*), array_func2(10), y end function array_func2 end interface real :: x(:) x = array_func2(x, 1.0) end subroutine test2 If we postpone the copy-out until after the assignment, then the result may be wrong. | 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][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][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] translate pure and elemental attribute in FIR (#109954) Follow-up from a previous patch that turned bind_c into an enum for procedure attribute. This patch carries the elemental and pure Fortran attribute into FIR so that the optimizer can leverage that info in the future (I think debug info may also need to know these aspects since DWARF has DW_AT_elemental and DW_AT_pure nodes). SIMPLE from F2023 will be translated once it is handled in the front-end. NON_RECURSIVE is only meaningful on func.func since we are not guaranteed to know that aspect on the caller side (it is not part of Fortran characteristics). There is a DW_AT_recursive DWARF node. I will do it while dealing with func.func attributes. | 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] Enable polymorphic lowering by default (#83285) Polymorphic entity lowering status is good. The main remaining TODO is to allow lowering of vector subscripted polymorphic entity, but this does not deserve blocking all application using polymorphism. Remove experimental option and enable lowering of polymorphic entity by default. | 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][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][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][NFC] turn fir.call is_bind_c into enum for procedure flags (#105691) First patch to fix a BIND(C) ABI issue (https://github.com/llvm/llvm-project/issues/102113). I need to keep track of BIND(C) in more locations (fir.dispatch and func.func operations), and I need to fix a few passes that are dropping the attribute on the floor. Since I expect more procedure attributes that cannot be reflected in mlir::FunctionType will be needed for ABI, optimizations, or debug info, this NFC patch adds a new enum attribute to keep track of procedure attributes in the IR. This patch is not updating lowering to lower more attributes, this will be done in a separate patch to keep the test changes low here. Adding the attribute on fir.dispatch and func.func will also be done in separate patches. | 1 年前 | |
[flang] fix ICE with ignore_tkr(tk) character in explicit interface (#140885) Some MPI libraries use character dummies + ignore(TKR) to allow passing any kind of buffer. This was meant to already be handled by #108168 However, when the library interface also had an argument requiring an explicit interface, builder.convertWithSemantics was not allowed to properly deal with the actual/dummy type mismatch and generated bad IR causing errors like: 'fir.convert' op invalid type conversion'!fir.ref' / '!fir.boxchar\<1\>'. This restriction was artificial, lowering should just handle any cases allowed by semantics. Just remove it. | 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] 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] 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] Give internal linkage to internal procedures (#81929) Internal procedures cannot be called directly from outside the host procedure, so there is no point giving them external linkage. The only reason flang did is because it is the default in MLIR. Giving external linkage to them: - prevents deleting them when not used/inlined by LLVM - causes bugs with shared libraries (at least on linux x86-64) because the call to the internal function could lead to a dynamic loader call that would overwrite r10 register (the static chain pointer) due to system calls and did not restore (it seems it does not expect r10 to be used for PLT calls). This patch gives internal linkage to internal procedures: Note: the llvm.linkage attribute name cannot be obtained via a getLinkageAttrName since it is not the same name as the one used in the LLVM dialect. It is just a placeholder defined in mlir/lib/Conversion/FuncToLLVM/FuncToLLVM.cpp until the func dialect gets a real linkage model. So simply avoid hard coding it too many times in lowering. | 2 年前 | |
[flang] Retain internal and BIND(C) host procedure link in FIR (#87796) Currently, it is not possible to find back which fun.func is the host procedure of some internal procedure because the mangling of the internal procedure does not contain info about the BIND(C) name of the host. This info may be useful to ensure dwarf DW_TAG_subprogram of internal procedures are nested under DW_TAG_subprogram of host procedures for instance. | 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][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] Enable polymorphic lowering by default (#83285) Polymorphic entity lowering status is good. The main remaining TODO is to allow lowering of vector subscripted polymorphic entity, but this does not deserve blocking all application using polymorphism. Remove experimental option and enable lowering of polymorphic entity by default. | 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][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] Main program symbol no longer conflicts with the other symbols (#149169) The following code is now accepted: module m end program m use m end The PROGRAM name doesn't really have an effect on the compilation result, so it shouldn't result in symbol name conflicts. This change makes the main program symbol name all uppercase in the cooked character stream. This makes it distinct from all other symbol names that are all lowercase in cooked character stream. Modified the tests that were checking for lower case main program name. | 1 年前 | |
[flang] simplify pointer assignments (#168732) Pointer assignment lowering was done in different ways depending on contexts and types, sometimes still using runtime calls when this is not needed and the complexity of doing this inline is very limited (the pointer and target descriptors were already prepared inline, the runtime is just doing the descriptor assignment and ensuring the pointer descriptor keep its pointer flag). Slightly extent the inline version that was used for Forall and use it for all cases. When lowering without HLFIR is removed, this will allow removing more code. | 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][hlfir] support optional args for intrinsic ops This also adds support for allocatable non-optional arguments. Of the transformational intrinsics which currently have their own hlfir operations, all of the dynamically optional arguments are lowered as boxes, so that is all that is implemented for now. One alternative approach would have been to deal with the dynamically optional arguments when lowering to FIR runtime calls. I decided not to do this so that any passes working on the intrinsic operations would not have to know about and handle the dynamically optional arguments. Depends on D154235 Differential Revision: https://reviews.llvm.org/D154236 | 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][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][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][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] do not merge block after lowering Lowering relies on dead code generation / unreachable block deletion to delete some code that is potentially invalid. However, calling mlir::simplifyRegion also merges block, which may promote SSA values to block arguments. Not all FIR types are intended to be block arguments. The added test shows an example where block merging led to fir.shape<> being block arguments (and a failure later in codegen). Reviewed By: tblah, clementval, vdonaldson Differential Revision: https://reviews.llvm.org/D153858 | 3 年前 | |
[flang] Further work on NULL(MOLD=allocatable) (#129345) Refine handling of NULL(...) in semantics to properly distinguish NULL(), NULL(objectPointer), NULL(procPointer), and NULL(allocatable) from each other in relevant contexts. Add IsNullAllocatable() and IsNullPointerOrAllocatable() utility functions. IsNullAllocatable() is true only for NULL(allocatable); it is false for a bare NULL(), which can be detected independently with IsBareNullPointer(). IsNullPointer() now returns false for NULL(allocatable). ALLOCATED(NULL(allocatable)) now works, and folds to .FALSE. These utilities were modified to accept const pointer arguments rather than const references; I usually prefer this style when the result should clearly be false for a null argument (in the C sense), and it helped me find all of their use sites in the code. | 1 年前 | |
[flang] Enable polymorphic lowering by default (#83285) Polymorphic entity lowering status is good. The main remaining TODO is to allow lowering of vector subscripted polymorphic entity, but this does not deserve blocking all application using polymorphism. Remove experimental option and enable lowering of polymorphic entity by default. | 2 年前 | |
[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] 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] Make the parent type the first component (#69348) Type extension is currently handled in FIR by inlining the parents components as the first member of the record type. This is not correct from a memory layout point of view since the storage size of the parent type may be bigger than the sum of the size of its component (due to alignment requirement). To avoid making FIR types target dependent and fix this issue, make the parent component a single component with the parent type at the beginning of the record type. This also simplifies addressing since parent component is now a "normal" component that can be designated with hlfir.designate. StructureComponent lowering however is a bit more complex since the symbols in the structure component may refer to subcomponents of parent types. Notes: 1. The fix is only done in HLFIR for now, a similar fix should be done in ConvertExpr.cpp to fix the path without HLFIR (I will likely still do it in a new patch since it would be an annoying bug to investigate for people testing flang without HLFIR). 2. The private component extra mangling is useless after this patch. I will remove it after 1. 3. The "parent component" TODO in constant CTOR is free to implement for HLFIR after this patch, but I would rather remove it and test it in a different patch. | 2 年前 | |
[flang] Expand parent component in procedure pointer component ref (#78593) For simplicity, lowering relies on semantics expansion of parent components in designators. This was not done in call x%p() where p is a procedure component pointer of a parent component of x. Do it and turn lowering TODO into a new lowering TODO for call bar(x%type_bound_procedure) (passing a tybe bound procedure is allowed as an extension, but lowering does not handle this extension yet. This is a lowering issue, will do in different patch). | 2 年前 | |
[flang] simplify pointer assignments (#168732) Pointer assignment lowering was done in different ways depending on contexts and types, sometimes still using runtime calls when this is not needed and the complexity of doing this inline is very limited (the pointer and target descriptors were already prepared inline, the runtime is just doing the descriptor assignment and ensuring the pointer descriptor keep its pointer flag). Slightly extent the inline version that was used for Forall and use it for all cases. When lowering without HLFIR is removed, this will allow removing more code. | 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] Set func.func arg attributes for procedure designators (#68420) Currently, if the first usage of a procedure not defined in the file was inside a procedure designator reference (not a call to it), the lowered func.func lacked the argument attributes if any. Fix this by using CallInterface<T>::declare too in SignatureBuilder to create a new func.func instead of using custom code. Note: this problem was made worse by the fact that module variables fir.global are currently lowered before the module procedures func.func are created. I will try to fix that in a later patch (the debug location may still be wrong in certain cases) because there is quite some test fallout when changing the order of globals/funcop in the output. | 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][NFC] Strip trailing whitespace from tests (3 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] Main program symbol no longer conflicts with the other symbols (#149169) The following code is now accepted: module m end program m use m end The PROGRAM name doesn't really have an effect on the compilation result, so it shouldn't result in symbol name conflicts. This change makes the main program symbol name all uppercase in the cooked character stream. This makes it distinct from all other symbol names that are all lowercase in cooked character stream. Modified the tests that were checking for lower case main program name. | 1 年前 | |
| 1 年前 | ||
[flang] simplify pointer assignments (#168732) Pointer assignment lowering was done in different ways depending on contexts and types, sometimes still using runtime calls when this is not needed and the complexity of doing this inline is very limited (the pointer and target descriptors were already prepared inline, the runtime is just doing the descriptor assignment and ensuring the pointer descriptor keep its pointer flag). Slightly extent the inline version that was used for Forall and use it for all cases. When lowering without HLFIR is removed, this will allow removing more code. | 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][NFC] Strip trailing whitespace from tests (3 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][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] 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][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] Separate -emit-fir and -emit-hlfir for bbc In review for https://reviews.llvm.org/D146278, @vzakhari asked to separate -emit-fir and -emit-hlfir. This will allow FIR to be easily outputted after the HLFIR passes have been run. The new semantics are as follows: | Action | -hlfir? | Result | | =========== | ======= | =============================== | | -emit-hlfir | N | Outputs HLFIR | | -emit-hlfir | Y | Outputs HLFIR | | -emit-fir | N | Outputs FIR, using old lowering | | -emit-fir | Y | Outputs FIR, lowering via HLFIR | This is tested in flang/test/HLFIR/hlfir-flags.f90 Depends on: D151088 Differential Revision: https://reviews.llvm.org/D151108 | 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] Support type descriptor for initialized character component These compiler generated component descriptor include designators packaged as CLASS(*) for simplicity. HLFIR hit an assert in an std::get trying to recover an Expr<SomeChar> while translating the expression type. Use the dynamic type of the CLASS(*) expr in that case to recover the compiler length. Differential Revision: https://reviews.llvm.org/D144960 | 3 年前 | |
[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] Enable polymorphic lowering by default (#83285) Polymorphic entity lowering status is good. The main remaining TODO is to allow lowering of vector subscripted polymorphic entity, but this does not deserve blocking all application using polymorphism. Remove experimental option and enable lowering of polymorphic entity by default. | 2 年前 | |
[flang][hlfir] Support type bound procedure in type descriptors In hlfir, procedure designators are propagated as fir.box_proc. Derived type descriptors are compiler generated constant structure constructors. They contain CFPTR components for the type bound procedure addresses. Before being cast to an integer type so that they can be stored in the CFPTR components, the fir.box_proc addresses must be obtained with a fir.box_addr. Differential Revision: https://reviews.llvm.org/D144952 | 3 年前 | |
| 1 年前 | ||
[flang][hlfir] Make the parent type the first component (#69348) Type extension is currently handled in FIR by inlining the parents components as the first member of the record type. This is not correct from a memory layout point of view since the storage size of the parent type may be bigger than the sum of the size of its component (due to alignment requirement). To avoid making FIR types target dependent and fix this issue, make the parent component a single component with the parent type at the beginning of the record type. This also simplifies addressing since parent component is now a "normal" component that can be designated with hlfir.designate. StructureComponent lowering however is a bit more complex since the symbols in the structure component may refer to subcomponents of parent types. Notes: 1. The fix is only done in HLFIR for now, a similar fix should be done in ConvertExpr.cpp to fix the path without HLFIR (I will likely still do it in a new patch since it would be an annoying bug to investigate for people testing flang without HLFIR). 2. The private component extra mangling is useless after this patch. I will remove it after 1. 3. The "parent component" TODO in constant CTOR is free to implement for HLFIR after this patch, but I would rather remove it and test it in a different patch. | 2 年前 | |
[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 年前 | |
Reland [VPlan] Expand WidenInt inductions with nuw/nsw (#168354) Changes: The previous patch had to be reverted to a mismatching-OpType assert in cse. The reduced-test has now been added corresponding to a RVV pointer-induction, and the pointer-induction case has been updated to use createOverflowingBinaryOp. While at it, record VPIRFlags in VPWidenInductionRecipe. | 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] Change uniqueCGIdent separator from . to X (#71338) Change the separator in the uniqueCGIdent method to X. This change is required to enable OpenMP offloading for the NVPTX target, as dots are not valid identifiers in PTX and uniqueCGIdent is used to mangle some literals. Follow up patches will change the remainder of . appearances in names to X and add support for the NVPTX target. | 2 年前 | |
[flang] optimize array function calls using hlfir.eval_in_mem (#118070) This patch encapsulate array function call lowering into hlfir.eval_in_mem and allows directly evaluating the call into the LHS when possible. The conditions are: LHS is contiguous, not accessed inside the function, it is not a whole allocatable, and the function results needs not to be finalized. All these conditions are tested in the previous hlfir.eval_in_mem optimization (#118069) that is leveraging the extension of getModRef to handle function calls(#117164). This yields a 25% speed-up on polyhedron channel2 benchmark (from 1min to 45s measured on an X86-64 Zen 2). | 1 年前 | |
[flang][hlfir] Return function call result as AsExpr. (#67769) This should help inlining elemental into another elemental, and also will help to get rid of unnecessary deep copies in bufferization. | 2 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 8 个月前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 8 个月前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 3 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 3 年前 | ||
| 8 个月前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 3 年前 | ||
| 10 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 |