| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[flang] Added coarse grained alias analysis for FIR. These are experimental changes in Flang AA to provide at least some means to disambiguate memory accesses in some simple cases. This AA is still not used by any transformation, so the LIT tests are the only way to trigger it currently. I will further look into applying this AA within Flang to address some of the known performance issues in the benchmarks. Credits to @Renaud-K for the initial implementation. Differential Revision: https://reviews.llvm.org/D141410 | 3 年前 | |
[flang] AliasAnalysis: Handle fir.load on fir.alloca (#117785) For example, determine that the address in p below cannot alias the address of v: subroutine test() real, pointer :: p real, target :: t real :: v p => t v = p end subroutine test | 1 年前 | |
| 1 年前 | ||
[flang] approximate alias analysis support for hlfir.designate Add a rough alias analysis rule for hlfir.designate which just follows the memref argument. This could be extended in the future to take into account the indices or derived type fields accessed to spot for provably non-overlapping cases. In the meantime, we need a flag to ensure we never say "MustAlias" when following a value through a hlfir.designate because the designate analysis is only approximate. Differential Revision: https://reviews.llvm.org/D157718 | 2 年前 | |
[flang] Follow memory source through more operations (#66713) Add support for fir.box_addr, fir.array_corr, fir.coordinate, fir.embox, fir.rebox and fir.load. 1) Through the use of boolean followBoxAddr determine whether the analysis should apply to the address of the box or the address wrapped by the box. 2) Some asserts have been removed to allow for more SourceKinds though the flow, in a particular SourceKind::Direct 3) getSource was a public method but the returned type (SourceKind) was not public making it impossible to be called publicly 4) About 12 tests have been added to check for real Fortran scenarios 5) More tests will be added with HLFIR 6) A few TODOs have been identified and will need to be addressed in follow-up patches. I felt that more changes would increase the complexity of the patch. | 2 年前 | |
[flang][hlfir] Make alias analysis trace through box designators. (#67353) The changes are needed to get leslie3d same performance with HLFIR as with FIR lowering. The two module allocatable variables cannot alias, so the optimized bufferization should be able to elide the temporary and inline the assignment loop. | 2 年前 | |
[flang][hlfir] Make alias analysis trace through box designators. (#67353) The changes are needed to get leslie3d same performance with HLFIR as with FIR lowering. The two module allocatable variables cannot alias, so the optimized bufferization should be able to elide the temporary and inline the assignment loop. | 2 年前 | |
[flang] Improve alias analysis to be precise for box and box.base_addr (#80335) After PR#68727 the source for both the fir.box_addr and a box became the same. Thus the detection that only one of the sources was direct and the special logic around it was being skipped. As a result, the test included would show a "MayAlias" result instead of a "NoAlias" result. | 2 年前 | |
[Flang][AliasAnalysis] Alias analysis for tmp arrays (#111972) This patch extends the alias analysis for temporary arrays in Flang. With this extension, Flang can now determine that the temporary array [a, b, c] does not alias with arrayD in Fortran code: integer :: a, b, c integer :: arrayD(3) arrayD = [ a, b, c ] | 1 年前 | |
[flang][hlfir] Make alias analysis trace through box designators. (#67353) The changes are needed to get leslie3d same performance with HLFIR as with FIR lowering. The two module allocatable variables cannot alias, so the optimized bufferization should be able to elide the temporary and inline the assignment loop. | 2 年前 | |
[mlir][OpenMP][flang] make private variable allocation implicit in omp.private (#124019) The intention of this work is to give MLIR->LLVMIR conversion freedom to control how the private variable is allocated so that it can be allocated on the stack in ordinary cases or as part of a structure used to give closure context for tasks which might outlive the current stack frame. See RFC: https://discourse.llvm.org/t/rfc-openmp-supporting-delayed-task-execution-with-firstprivate-variables/83084 For example, a privatizer for an integer used to look like mlir omp.private {type = private} @x.privatizer : !fir.ref<i32> alloc { ^bb0(%arg0: !fir.ref<i32>): %0 = ... allocate proper memory for the private clone ... omp.yield(%0 : !fir.ref<i32>) } After this change, allocation become implicit in the operation: mlir omp.private {type = private} @x.privatizer : i32 For more complex types that require initialization after allocation, an init region can be used: mlir omp.private {type = private} @x.privatizer : !some.type init { ^bb0(%arg0: !some.pointer<!some.type>, %arg1: !some.pointer<!some.type>): // initialize %arg1, using %arg0 as a mold for allocations omp.yield(%arg1 : !some.pointer<!some.type>) } dealloc { ^bb0(%arg0: !some.pointer<!some.type>): ... deallocate memory allocated by the init region ... omp.yield } This patch lays the groundwork for delayed task execution but is not enough on its own. After this patch all gfortran tests which previously passed still pass. There are the following changes to the Fujitsu test suite: - 0380_0009 and 0435_0009 are fixed - 0688_0041 now fails at runtime. This patch is testing firstprivate variables with tasks. Previously we got lucky with the undefined behavior and won the race. After these changes we no longer get lucky. This patch lays the groundwork for a proper fix for this issue. In flang the lowering re-uses the existing lowering used for reduction init and dealloc regions. In flang, before this patch we hit a TODO with the same wording when generating the copy region for firstprivate polymorphic variables. After this patch the box-like fir.class is passed by reference into the copy region, leading to a different path that didn't hit that old TODO but the generated code still didn't work so I added a new TODO in DataSharingProcessor. | 1 年前 | |
[MLIR][OpenMP] Improve omp.map.info verification (#132066) This patch makes the map_type and map_capture_type arguments of the omp.map.info operation required, which was already an invariant being verified by its users via verifyMapClause(). This makes it clearer, as getters no longer return misleading std::optional values. Checks for the mapper_id argument are moved to a verifier for the operation, rather than being checked by users. Functionally NFC, but not marked as such due to a reordering of arguments in the assembly format of omp.map.info. | 1 年前 | |
[OpenMP][Flang] Enable alias analysis inside omp target region (#111670) At present, alias analysis does not work for operations inside OMP target regions because the FIR declare operations within OMP target do not offer sufficient information for alias analysis. Consequently, it is necessary to examine the FIR code outside the OMP target region. | 1 年前 | |
[mlir][OpenMP][flang] make private variable allocation implicit in omp.private (#124019) The intention of this work is to give MLIR->LLVMIR conversion freedom to control how the private variable is allocated so that it can be allocated on the stack in ordinary cases or as part of a structure used to give closure context for tasks which might outlive the current stack frame. See RFC: https://discourse.llvm.org/t/rfc-openmp-supporting-delayed-task-execution-with-firstprivate-variables/83084 For example, a privatizer for an integer used to look like mlir omp.private {type = private} @x.privatizer : !fir.ref<i32> alloc { ^bb0(%arg0: !fir.ref<i32>): %0 = ... allocate proper memory for the private clone ... omp.yield(%0 : !fir.ref<i32>) } After this change, allocation become implicit in the operation: mlir omp.private {type = private} @x.privatizer : i32 For more complex types that require initialization after allocation, an init region can be used: mlir omp.private {type = private} @x.privatizer : !some.type init { ^bb0(%arg0: !some.pointer<!some.type>, %arg1: !some.pointer<!some.type>): // initialize %arg1, using %arg0 as a mold for allocations omp.yield(%arg1 : !some.pointer<!some.type>) } dealloc { ^bb0(%arg0: !some.pointer<!some.type>): ... deallocate memory allocated by the init region ... omp.yield } This patch lays the groundwork for delayed task execution but is not enough on its own. After this patch all gfortran tests which previously passed still pass. There are the following changes to the Fujitsu test suite: - 0380_0009 and 0435_0009 are fixed - 0688_0041 now fails at runtime. This patch is testing firstprivate variables with tasks. Previously we got lucky with the undefined behavior and won the race. After these changes we no longer get lucky. This patch lays the groundwork for a proper fix for this issue. In flang the lowering re-uses the existing lowering used for reduction init and dealloc regions. In flang, before this patch we hit a TODO with the same wording when generating the copy region for firstprivate polymorphic variables. After this patch the box-like fir.class is passed by reference into the copy region, leading to a different path that didn't hit that old TODO but the generated code still didn't work so I added a new TODO in DataSharingProcessor. | 1 年前 | |
[mlir][OpenMP][flang] make private variable allocation implicit in omp.private (#124019) The intention of this work is to give MLIR->LLVMIR conversion freedom to control how the private variable is allocated so that it can be allocated on the stack in ordinary cases or as part of a structure used to give closure context for tasks which might outlive the current stack frame. See RFC: https://discourse.llvm.org/t/rfc-openmp-supporting-delayed-task-execution-with-firstprivate-variables/83084 For example, a privatizer for an integer used to look like mlir omp.private {type = private} @x.privatizer : !fir.ref<i32> alloc { ^bb0(%arg0: !fir.ref<i32>): %0 = ... allocate proper memory for the private clone ... omp.yield(%0 : !fir.ref<i32>) } After this change, allocation become implicit in the operation: mlir omp.private {type = private} @x.privatizer : i32 For more complex types that require initialization after allocation, an init region can be used: mlir omp.private {type = private} @x.privatizer : !some.type init { ^bb0(%arg0: !some.pointer<!some.type>, %arg1: !some.pointer<!some.type>): // initialize %arg1, using %arg0 as a mold for allocations omp.yield(%arg1 : !some.pointer<!some.type>) } dealloc { ^bb0(%arg0: !some.pointer<!some.type>): ... deallocate memory allocated by the init region ... omp.yield } This patch lays the groundwork for delayed task execution but is not enough on its own. After this patch all gfortran tests which previously passed still pass. There are the following changes to the Fujitsu test suite: - 0380_0009 and 0435_0009 are fixed - 0688_0041 now fails at runtime. This patch is testing firstprivate variables with tasks. Previously we got lucky with the undefined behavior and won the race. After these changes we no longer get lucky. This patch lays the groundwork for a proper fix for this issue. In flang the lowering re-uses the existing lowering used for reduction init and dealloc regions. In flang, before this patch we hit a TODO with the same wording when generating the copy region for firstprivate polymorphic variables. After this patch the box-like fir.class is passed by reference into the copy region, leading to a different path that didn't hit that old TODO but the generated code still didn't work so I added a new TODO in DataSharingProcessor. | 1 年前 | |
| 1 年前 | ||
[flang][NFCI] Stop tracking memory source after a load in a more explicit manner. (#126156) Typically, we do not track memory sources after a load because of the dynamic nature of the load and the fact that the alias analysis is a simple static analysis. However, the code is written in a way that makes it seem like we are continuing to track memory but in reality we are only doing so when we know that the tracked memory is a leaf and therefore when there will only be one more iteration through the switch statement. In other words, we are iterating one more time, to gather data about a box, anticipating that this will be the last time. This is a hack that helped avoid cut-and-paste from other case statements but gives the wrong impression about the intention of the code and makes it confusing. To make it clear that there is no more tracking, we gather all the necessary data from the memref of the load, in the case statement for the load, and exit the loop. I am also limiting this data gathering for the case when we load a box reference while we were actually following data, as tests have shows, is the only case when we need it for. Other cases will be handled conservatively, but this can change in the future, on a case-by-case basis. --------- Co-authored-by: Joel E. Denny <jdenny.ornl@gmail.com> | 1 年前 | |
[flang][cuf] Add to cuf.alloc/cuf.allocate mem alloc effect (#167414) Add MemAlloc effect to the result so that cuf.alloc/cuf.allocate can be recognized by FIR alias analysis. | 8 个月前 | |
[flang] handle fir.call in AliasAnalysis::getModRef (#117164) fir.call side effects are hard to describe in a useful way using MemoryEffectOpInterface because it is impossible to list which memory location a user procedure read/write without doing a data flow analysis of its body (even PURE procedures may read from any module variable, Fortran SIMPLE procedure from F2023 will allow that, but they are far from common at that point). Fortran language specifications allow the compiler to deduce that a procedure call cannot access a variable in many cases This patch leverages this to extend fir::AliasAnalysis::getModRef to deal with fir.call. This will allow implementing "array = array_function()" optimization in a future patch. | 1 年前 | |
[flang] AliasAnalysis: Handle fir.load on fir.alloca (#117785) For example, determine that the address in p below cannot alias the address of v: subroutine test() real, pointer :: p real, target :: t real :: v p => t v = p end subroutine test | 1 年前 | |
| 1 年前 | ||
[flang] handle fir.call in AliasAnalysis::getModRef (#117164) fir.call side effects are hard to describe in a useful way using MemoryEffectOpInterface because it is impossible to list which memory location a user procedure read/write without doing a data flow analysis of its body (even PURE procedures may read from any module variable, Fortran SIMPLE procedure from F2023 will allow that, but they are far from common at that point). Fortran language specifications allow the compiler to deduce that a procedure call cannot access a variable in many cases This patch leverages this to extend fir::AliasAnalysis::getModRef to deal with fir.call. This will allow implementing "array = array_function()" optimization in a future patch. | 1 年前 | |
[flang] handle fir.call in AliasAnalysis::getModRef (#117164) fir.call side effects are hard to describe in a useful way using MemoryEffectOpInterface because it is impossible to list which memory location a user procedure read/write without doing a data flow analysis of its body (even PURE procedures may read from any module variable, Fortran SIMPLE procedure from F2023 will allow that, but they are far from common at that point). Fortran language specifications allow the compiler to deduce that a procedure call cannot access a variable in many cases This patch leverages this to extend fir::AliasAnalysis::getModRef to deal with fir.call. This will allow implementing "array = array_function()" optimization in a future patch. | 1 年前 | |
[flang] handle fir.call in AliasAnalysis::getModRef (#117164) fir.call side effects are hard to describe in a useful way using MemoryEffectOpInterface because it is impossible to list which memory location a user procedure read/write without doing a data flow analysis of its body (even PURE procedures may read from any module variable, Fortran SIMPLE procedure from F2023 will allow that, but they are far from common at that point). Fortran language specifications allow the compiler to deduce that a procedure call cannot access a variable in many cases This patch leverages this to extend fir::AliasAnalysis::getModRef to deal with fir.call. This will allow implementing "array = array_function()" optimization in a future patch. | 1 年前 | |
[flang] handle fir.call in AliasAnalysis::getModRef (#117164) fir.call side effects are hard to describe in a useful way using MemoryEffectOpInterface because it is impossible to list which memory location a user procedure read/write without doing a data flow analysis of its body (even PURE procedures may read from any module variable, Fortran SIMPLE procedure from F2023 will allow that, but they are far from common at that point). Fortran language specifications allow the compiler to deduce that a procedure call cannot access a variable in many cases This patch leverages this to extend fir::AliasAnalysis::getModRef to deal with fir.call. This will allow implementing "array = array_function()" optimization in a future patch. | 1 年前 | |
[flang][NFC] Strip trailing whitespace from tests (2 of N) Only the fortran source files in flang/test have been modified. The other files in the directory will be cleaned up in subsequent commits | 9 个月前 | |
[flang] handle fir.call in AliasAnalysis::getModRef (#117164) fir.call side effects are hard to describe in a useful way using MemoryEffectOpInterface because it is impossible to list which memory location a user procedure read/write without doing a data flow analysis of its body (even PURE procedures may read from any module variable, Fortran SIMPLE procedure from F2023 will allow that, but they are far from common at that point). Fortran language specifications allow the compiler to deduce that a procedure call cannot access a variable in many cases This patch leverages this to extend fir::AliasAnalysis::getModRef to deal with fir.call. This will allow implementing "array = array_function()" optimization in a future patch. | 1 年前 | |
[flang] handle fir.call in AliasAnalysis::getModRef (#117164) fir.call side effects are hard to describe in a useful way using MemoryEffectOpInterface because it is impossible to list which memory location a user procedure read/write without doing a data flow analysis of its body (even PURE procedures may read from any module variable, Fortran SIMPLE procedure from F2023 will allow that, but they are far from common at that point). Fortran language specifications allow the compiler to deduce that a procedure call cannot access a variable in many cases This patch leverages this to extend fir::AliasAnalysis::getModRef to deal with fir.call. This will allow implementing "array = array_function()" optimization in a future patch. | 1 年前 | |
[flang] handle fir.call in AliasAnalysis::getModRef (#117164) fir.call side effects are hard to describe in a useful way using MemoryEffectOpInterface because it is impossible to list which memory location a user procedure read/write without doing a data flow analysis of its body (even PURE procedures may read from any module variable, Fortran SIMPLE procedure from F2023 will allow that, but they are far from common at that point). Fortran language specifications allow the compiler to deduce that a procedure call cannot access a variable in many cases This patch leverages this to extend fir::AliasAnalysis::getModRef to deal with fir.call. This will allow implementing "array = array_function()" optimization in a future patch. | 1 年前 | |
| 1 年前 | ||
Test fix: Adding REQUIRES: asserts (#130314) | 1 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 |