[all-commits] [llvm/llvm-project] 670aee: [MLIR][OpenMP][SCF] Mark parallel regions as alloc...

William Moses via All-commits all-commits at lists.llvm.org
Fri Feb 18 08:06:44 PST 2022


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 670aeece51ae0e4029d078fe3a5f06b50d42f15c
      https://github.com/llvm/llvm-project/commit/670aeece51ae0e4029d078fe3a5f06b50d42f15c
  Author: William S. Moses <gh at wsmoses.com>
  Date:   2022-02-18 (Fri, 18 Feb 2022)

  Changed paths:
    M mlir/include/mlir/Dialect/Affine/IR/AffineOps.td
    M mlir/include/mlir/Dialect/GPU/GPUOps.td
    M mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
    M mlir/include/mlir/Dialect/SCF/SCFOps.td
    M mlir/test/Conversion/VectorToSCF/vector-to-scf.mlir

  Log Message:
  -----------
  [MLIR][OpenMP][SCF] Mark parallel regions as allocation scopes

MLIR has the notion of allocation scopes which specify that stack allocations (e.g. memref.alloca, llvm.alloca) should be freed or equivalently aren't available at the end of the corresponding region.
Currently neither OpenMP parallel nor SCF parallel regions have the notion of such a scope.

This clearly makes sense for an OpenMP parallel as this is implemented in with a new function which outlines the region, and clearly any allocations in that newly outlined function have a lifetime that ends at the return of the function, by definition.

While SCF.parallel doesn't have a guaranteed runtime which it is implemented with, this similarly makes sense for SCF.parallel since otherwise an allocation within an SCF.parallel will needlessly continue to allocate stack memory that isn't cleaned up until the function (or other allocation scope op) which contains the SCF.parallel returns. This means that it is impossible to represent thread or iteration-local memory without causing a stack blow-up. In the case that this stack-blow-up behavior is intended, this can be equivalently represented with an allocation outside of the SCF.parallel with a size equal to the number of iterations.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D119743




More information about the All-commits mailing list