[all-commits] [llvm/llvm-project] e8d5db: [LoopPeeling] Fix weights updating of peeled off b...

[Aleksandr Popov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e8d5db206c2f5c4afac8288ab96193a5638270ae
      https://github.com/llvm/llvm-project/commit/e8d5db206c2f5c4afac8288ab96193a5638270ae
  Author: Aleksandr Popov <42888396+aleks-tmb at users.noreply.github.com>
  Date:   2023-10-31 (Tue, 31 Oct 2023)

  Changed paths:
    M llvm/lib/Transforms/Utils/LoopPeel.cpp
    M llvm/test/Transforms/LoopUnroll/peel-loop-pgo-deopt.ll
    M llvm/test/Transforms/LoopUnroll/peel-loop-pgo.ll

  Log Message:
  -----------
  [LoopPeeling] Fix weights updating of peeled off branches (#70094)

In https://reviews.llvm.org/D64235 a new algorithm has been introduced
for updating the branch weights of latch blocks and their copies.

It increases the probability of going to the exit block for each next
peel iteration, calculating weights by (F - I * E, E), where:
- F is a weight of the edge from latch to header.
- E is a weight of the edge from latch to exit.
- I is a number of peeling iteration.

E.g: Let's say the latch branch weights are (100,300) and the estimated
trip count is 4. If we peel off all 4 iterations the weights of the
copied branches will be:
0: (100,300)
1: (100,200)
2: (100,100)
3: (100,1)

https://godbolt.org/z/93KnoEsT6

So we make the original loop almost unreachable from the 3rd peeled copy
according to the profile data. But that's only true if the profiling
data is accurate.
Underestimated trip count can lead to a performance issues with the
register allocator, which may decide to spill intervals inside the loop
assuming it's unreachable.

Since we don't know how accurate the profiling data is, it seems better
to set neutral 1/1 weights on the last peeled latch branch. After this
change, the weights in the example above will look like this:
0: (100,300)
1: (100,200)
2: (100,100)
3: (100,100)

Co-authored-by: Aleksandr Popov <apopov at azul.com>