[all-commits] [llvm/llvm-project] fa99cb: [mlgo][regalloc] Add score calculation for training

[Mircea Trofin via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: fa99cb64ff0ea2d856107f73656e95ce6816ea1a
      https://github.com/llvm/llvm-project/commit/fa99cb64ff0ea2d856107f73656e95ce6816ea1a
  Author: Mircea Trofin <mtrofin at google.com>
  Date:   2021-12-07 (Tue, 07 Dec 2021)

  Changed paths:
    M llvm/lib/CodeGen/CMakeLists.txt
    A llvm/lib/CodeGen/RegAllocScore.cpp
    A llvm/lib/CodeGen/RegAllocScore.h
    M llvm/unittests/CodeGen/CMakeLists.txt
    A llvm/unittests/CodeGen/RegAllocScoreTest.cpp

  Log Message:
  -----------
  [mlgo][regalloc] Add score calculation for training

Add the calculation of a score, which will be used during ML training. The
score qualifies the quality of a regalloc policy, and is independent of
what we train (currently, just eviction), or the regalloc algo itself.
We can then use scores to guide training (which happens offline), by
formulating a reward based on score variation - the goal being lowering
scores (currently, that reward is percentage reduction relative to
Greedy's heuristic)

Currently, we compute the score by factoring different instruction
counts (loads, stores, etc) with the machine basic block frequency,
regardless of the instructions' provenance - i.e. they could be due to
the regalloc policy or be introduced previously. This is different from
RAGreedy::reportStats, which accummulates the effects of the allocator
alone. We explored this alternative but found (at least currently) that
the more naive alternative introduced here produces better policies. We
do intend to consolidate the two, however, as we are actively
investigating improvements to our reward function, and will likely want
to re-explore scoring just the effects of the allocator.

In either case, we want to decouple score calculation from allocation
algorighm, as we currently evaluate it after a few more passes after
allocation (also, because score calculation should be reusable
regardless of allocation algorithm).

We intentionally accummulate counts independently because it facilitates
per-block reporting, which we found useful for debugging - for instance,
we can easily report the counts indepdently, and then cross-reference
with perf counter measurements.

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