[all-commits] [llvm/llvm-project] eed72d: [mlir][ArmSME] Support filling liveness 'holes' in...

Benjamin Maxwell via All-commits all-commits at lists.llvm.org
Thu Jul 18 12:14:06 PDT 2024


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: eed72d4381261bfe1acb693fb8751c05765c4831
      https://github.com/llvm/llvm-project/commit/eed72d4381261bfe1acb693fb8751c05765c4831
  Author: Benjamin Maxwell <benjamin.maxwell at arm.com>
  Date:   2024-07-18 (Thu, 18 Jul 2024)

  Changed paths:
    M mlir/lib/Dialect/ArmSME/Transforms/TileAllocation.cpp
    M mlir/test/Dialect/ArmSME/tile-allocation-liveness.mlir

  Log Message:
  -----------
  [mlir][ArmSME] Support filling liveness 'holes' in the tile allocator (#98350)

Holes in a live range are points where the corresponding value does not
need to be in a tile/register. If the tile allocator keeps track of
these holes it can reuse tiles for more values (avoiding spills).

Take this simple example:

```mlir
func.func @example(%cond: i1) {
  %tileA = arm_sme.get_tile : vector<[4]x[4]xf32>
  cf.cond_br %cond, ^bb2, ^bb1
^bb1:
  // If we end up here we never use %tileA again!
  "test.some_use"(%tileB) : (vector<[4]x[4]xf32>) -> ()
  cf.br ^bb3
^bb2:
  "test.some_use"(%tileA) : (vector<[4]x[4]xf32>) -> ()
  cf.br ^bb3
^bb3:
  return
}
```

If you were to calculate the liveness of %tileA and %tileB. You'd see
there is a hole in the liveness of %tileA in bb1:

```
      %tileA  %tileB
^bb0:  Live
^bb1:          Live
^bb2:  Live
```

The tile allocator can make use of that hole and reuse the tile ID it
assigned to %tileA for %tileB.



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


More information about the All-commits mailing list