| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[flang][hlfir] Fixed KindMapping for HLFIR intrinsics lowering. hlfir.count lowering was using incorrect default integer kind by ignoring the kind specified in the ModuleOp. Reviewed By: tblah Differential Revision: https://reviews.llvm.org/D156017 | 3 年前 | |
[flang][hlfir] Add pass to inline elementals Implement hlfir.elemental inlining as proposed in flang/docs/HighLevelFIR.md. This is a separate pass to make the code easier to understand. One alternative would have been to modify the hlfir.elemental lowering in the HLFIR bufferization pass. Currently, a hlfir.elemental can only be inlined once; if there are more uses, the existing bufferization is used instead. Usage of mlir::applyPatternsAndFoldGreedily was suggested by @jeanPerier Differential Revision: https://reviews.llvm.org/D149258 | 3 年前 | |
[flang][hlfir] Fixed KindMapping for HLFIR intrinsics lowering. hlfir.count lowering was using incorrect default integer kind by ignoring the kind specified in the ModuleOp. Reviewed By: tblah Differential Revision: https://reviews.llvm.org/D156017 | 3 年前 | |
[flang][hlfir] Fixed KindMapping for HLFIR intrinsics lowering. hlfir.count lowering was using incorrect default integer kind by ignoring the kind specified in the ModuleOp. Reviewed By: tblah Differential Revision: https://reviews.llvm.org/D156017 | 3 年前 | |
[flang][hlfir] Fixed KindMapping for HLFIR intrinsics lowering. hlfir.count lowering was using incorrect default integer kind by ignoring the kind specified in the ModuleOp. Reviewed By: tblah Differential Revision: https://reviews.llvm.org/D156017 | 3 年前 | |
[flang][hlfir] Codegen of hlfir.region_assign where LHS conflicts When the analysis of hlfir.region_assign determined that the LHS region evaluation may be impacted by the assignment effects, all LHS must be fully evaluated and saved before any assignment is done. This patch adds TemporaryStorage variants to save address, including vector subscripted entities addresses whose shape must be saved. It uses the DescriptorStack runtime to deal with complex cases inside forall. For the sake of simplicity, this is also used for vector subscripted LHS outside of foralls (each element address is saved as a descriptor on this stack. This is a bit suboptimal, but it is a safe start that will work with all kinds of type (polymorphic, PDTs...) without further work). Another approach would be to saved only the values that are conflicting in the LHS computation, but this would require a much more complex analysis of the LHS region DAG. Differential Revision: https://reviews.llvm.org/D154057 | 3 年前 | |
[flang][hlfir] avoid useless LHS temporaries inside WHERE The need to save LHS addresses on a stack before doing an assignment is very limited: it is only really needed for forall and vectore subscripted LHS where the LHS cannot be computed as a descriptor. The previous current WHERE codegen was creating address stacks for LHS element addresses when the LHS evaluation conflicts with the assignment (may depend on the LHS value). This is not needed since the computed array designator for the LHS is already "saved" before the assignment from an SSA point of view. This patch prevents LHS temporary stack from being created outside of forall and vector subscripted assignments. Differential Revision: https://reviews.llvm.org/D154418 | 3 年前 | |
[flang][hlfir] Implement the scheduling part of hlfir.forall codegen The lowering of hlfir.forall to loops (and later hlfir.where) requires doing a data dependency analysis to avoid creating temporary storage for every control/mask/rhs/lhs expressions. The added code implements a data dependency analysis for the hlfir ordered assignment trees (it is not specific to Forall since these nodes includes Where, user defined assignments, and assignment to vector subscripted entities, but the added code is only plugged and tested with hlfir.forall in this patch). This data dependency analysis returns a "schedule", which is a list of runs containing actions. Each runs will result in a single loop nest evaluating all its action "at the same time" inside the loop body. Actions may either evaluating an assignment, or saving some expression evaluation (the value yielded inside the ordered assignment hlfir operations) in a temporary storage before doing the assignment that requires this expression value but may "conflict" with it. A "conflict" is a read in an expression E to a variable that is, or may be (analysis is conservative), written by an assignment that depends on E. The analysis is based on MLIR SideEffectInterface and fir AliasAnalysis which makes it generic. For now, the codegen that will apply the schedule and rewrite the hlfir.forall into a set of loops is not implemented, but the scheduling is tested on its own (from Fortran, because it allows testing many cases in very readable fashions). The current scheduling has limitations, for instance "forall(i=1, 10) x(i)=2*x(i)" does not require saving the RHS values for all "i" before doing the assignments since the RHS does not depend on values computed during previous iterations. Any user call will also trigger a conservative assumption that there is a conflict. Finally, a lot of operations are missing memory effect interfaces (especially in HLFIR). This patch adds a few so that it can be tested, but more will be added in later patches. Differential Revision: https://reviews.llvm.org/D150455 | 3 年前 | |
[flang][hlfir] Fixed KindMapping for HLFIR intrinsics lowering. hlfir.count lowering was using incorrect default integer kind by ignoring the kind specified in the ModuleOp. Reviewed By: tblah Differential Revision: https://reviews.llvm.org/D156017 | 3 年前 |