[all-commits] [llvm/llvm-project] 31087c: [flang] handle alloca outside of entry blocks in M...

[jeanPerier via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 31087c5e4c8ddfe08ab3ea6d3847e05c4738eeee
      https://github.com/llvm/llvm-project/commit/31087c5e4c8ddfe08ab3ea6d3847e05c4738eeee
  Author: jeanPerier <jperier at nvidia.com>
  Date:   2024-07-17 (Wed, 17 Jul 2024)

  Changed paths:
    M flang/include/flang/Optimizer/Builder/FIRBuilder.h
    M flang/include/flang/Optimizer/Dialect/FIROps.td
    A flang/include/flang/Optimizer/Transforms/MemoryUtils.h
    M flang/lib/Optimizer/Builder/FIRBuilder.cpp
    M flang/lib/Optimizer/Dialect/FIROps.cpp
    M flang/lib/Optimizer/Transforms/CMakeLists.txt
    M flang/lib/Optimizer/Transforms/MemoryAllocation.cpp
    A flang/lib/Optimizer/Transforms/MemoryUtils.cpp
    A flang/test/Fir/memory-allocation-opt-2.fir

  Log Message:
  -----------
  [flang] handle alloca outside of entry blocks in MemoryAllocation (#98457)

This patch generalizes the MemoryAllocation pass (alloca -> heap) to
handle fir.alloca regardless of their postion in the IR. Currently, it
only dealt with fir.alloca in function entry blocks. The logic is placed
in a utility that can be used to replace alloca in an operation on
demand to whatever kind of allocation the utility user wants via
callbacks (allocmem, or custom runtime calls to instrument the code...).

To do so, a concept of ownership, that was already implied a bit and
used in passes like stack-reclaim, is formalized. Any operation with the
LoopLikeInterface, AutomaticAllocationScope, or IsolatedFromAbove owns
the alloca directly nested inside its regions, and they must not be used
after the operation.

The pass then looks for the exit points of region with such interface,
and use that to insert deallocation. If dominance is not proved, the
pass fallbacks to storing the new address into a C pointer variable
created in the entry of the owning region which allows inserting
deallocation as needed, included near the alloca itself to avoid leaks
when the alloca is executed multiple times due to block CFGs loops.

This should fix https://github.com/llvm/llvm-project/issues/88344.

In a next step, I will try to refactor lowering a bit to introduce
lifetime operation for alloca so that the deallocation points can be
inserted as soon as possible.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications