[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