[all-commits] [llvm/llvm-project] 8d79b7: [Polly] Keep proximity dependence exact if simplif...

[Timur Baidusenov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 8d79b74443de46e78b4f2c90aa65bd42c491e909
      https://github.com/llvm/llvm-project/commit/8d79b74443de46e78b4f2c90aa65bd42c491e909
  Author: Timur Baidusenov <timurbaidusenov at gmail.com>
  Date:   2026-09-29 (Tue, 29 Sep 2026)

  Changed paths:
    M polly/lib/Transform/ScheduleOptimizer.cpp
    A polly/test/ScheduleOptimizer/simplify_deps_bounded_proximity.ll

  Log Message:
  -----------
  [Polly] Keep proximity dependence exact if simplifying it unbounds its distance (#225840)

Before calling the isl scheduler, `runIslScheduleOptimizer` gists the
dependences
with the iteration domains (`-polly-opt-simplify-deps=yes`, the default
since
a26db470834a, 2012). For a statement that reads a value written in one
iteration
of a loop in all later iterations, the gist also drops the upper bound
of that
loop:

{ S[k, i, k] -> S[k, i, j] : k < j <= n - 1 } becomes { S[k, i, k] ->
S[k, i, j] : j > k }

The proximity distance along j is then unbounded. isl's Pluto-like step
needs a
bound `u·n + w` on every proximity distance, finds no row that satisfies
it, and
falls back to carrying dependences one row at a time. For floyd-warshall
this
yields a wavefront over `i + j` below the `k` loop instead of a
permutable band
`(i, j)`. That band is never tiled, and the innermost loop walks the
array
diagonally.

The patch keeps the exact proximity dependence of a statement on itself
when
the gisted dependence has unbounded distances and the exact one has
bounded
distances. Validity dependences, and dependences between different
statements,
are still gisted. The cost of the exact dependences therefore only
applies to
the few maps where the gist removed the bound; heat-3d, where keeping
all
proximity dependences exact makes scheduling take minutes, is
unaffected.

### Measurements

x86-64 (Ryzen 7 9700X), `-O3 -march=native -mllvm -polly`, baseline is
the same
compiler without the change.

| | before | after | |
|---|---|---|---|
| PolyBench 4.2.1 LARGE floyd-warshall (min of 3, pinned) | 26.7 s | 6.8
s | 3.9x |
| llvm-test-suite floyd-warshall (min of 5, pinned) | 60.9 s | 16.4 s |
3.7x |
| compile time floyd-warshall.c (min of 5) | 131 ms | 134 ms | |
| .text floyd-warshall | 4775 | 6298 | |

- Among the 30 PolyBench kernels, only floyd-warshall generates
different code.
- In llvm-test-suite (SingleSource + MultiSource), only floyd-warshall
and two
small regression tests (Regression-C-test_indvars,
GCC-C-execute-20000422-1)
change. All 2137 tests pass in both configurations. The other objects
whose
code differed between the two builds (oggenc, two TSVC programs) differ
by
Polly's pre-existing run-to-run nondeterminism; the patch did not
trigger
  there.
- CTMark (`-j1`, pinned, 2 repetitions): identical generated code, total
compile
  time within noise.
- With the default 32x32 tiles, floyd-warshall is still 1.2x slower than
plain
-O3 on this machine. That is a tile size effect: with
`-polly-tile-sizes=16,32`
  the kernel runs in 1.6 s, 3.5x faster than -O3.

### Test

`polly/test/ScheduleOptimizer/simplify_deps_bounded_proximity.ll`:
floyd-warshall
with a parametric size; checks for the `(k)` band followed by the tiled
`(i, j)`
band. It fails without the patch, which produces the `(i + j)`
wavefront.

Assisted-by: Claude (Anthropic)



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