tblah added a comment. In D140415#4080080 <https://reviews.llvm.org/D140415#4080080>, @jdoerfert wrote:
> Did you check LLVM's heap2stack and the corresponding tests? > https://github.com/llvm/llvm-project/blob/c68af565ff0c2fdc5537e9ac0c2d7c75df44b035/llvm/lib/Transforms/IPO/AttributorAttributes.cpp#L6480 > https://github.com/llvm/llvm-project/blob/main/llvm/test/Transforms/Attributor/heap_to_stack.ll > https://github.com/llvm/llvm-project/blob/main/llvm/test/Transforms/Attributor/heap_to_stack_gpu.ll The LLVM pass seems to make quite different design decisions to this pass. The LLVM pass does limit the maximum size of allocations moved to the stack, but does not attempt to avoid placing allocations inside of loops (and does not seem to attempt to move allocations to the entry block). The LLVM pass also supports exceptions, which this pass does not (as there are no exceptions in Fortran). There is also a similar MLIR pass (promote buffers to stack). The MLIR pass operates on the memref dialect, which is a slightly different problem space because there are no explicit free() instructions to detect. Furthermore, the MLIR pass does not attempt to hoist allocations outside of loops and only detects structured loop operations (LoopLikeOpInterface) not loops formed from branch operations in the control flow graph. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D140415/new/ https://reviews.llvm.org/D140415 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
