[all-commits] [llvm/llvm-project] ce9af2: [CodeGen] Refactor rematerializer unit tests to re...

Tue Jun 9 06:21:10 PDT 2026

  Branch: refs/heads/users/lucas-rami/rematerializer-finegrain-lis-update
  Home:   https://github.com/llvm/llvm-project
  Commit: ce9af23750fee2ed28cb5268edfc8d8b01ae80e3
      https://github.com/llvm/llvm-project/commit/ce9af23750fee2ed28cb5268edfc8d8b01ae80e3
  Author: Lucas Ramirez <lucas.rami at proton.me>
  Date:   2026-05-20 (Wed, 20 May 2026)

  Changed paths:
    M llvm/unittests/CodeGen/RematerializerTest.cpp

  Log Message:
  -----------
  [CodeGen] Refactor rematerializer unit tests to reduce boilerplate (NFC)

Taking inspiration from other unit tests, this refactors the
rematerializer's unit tests with the aim of reducing the amount of
repetitive boilerplate code in each test, making the addition of new
tests easier/faster in the future.

Each unit test defines some input MIR to instantiate a rematerializer
on; a user-provided callback is then invoked with a pre-initialized
rematerializer wrapped in a helper object that factors out as much
common verification logic as possible.

  Commit: bdd060475f53929dc007965eece438111550c2fc
      https://github.com/llvm/llvm-project/commit/bdd060475f53929dc007965eece438111550c2fc
  Author: Lucas Ramirez <lucas.rami at proton.me>
  Date:   2026-05-20 (Wed, 20 May 2026)

  Changed paths:
    M llvm/include/llvm/CodeGen/Rematerializer.h
    M llvm/lib/CodeGen/Rematerializer.cpp
    M llvm/unittests/CodeGen/RematerializerTest.cpp

  Log Message:
  -----------
  [CodeGen] Fix incorrect rematerialization rollback order

This fixes an issue in the rematerializer's rollbacker wherein adjacent
MIs that were deleted through rematerializations would
sometimes---depending on the exact order in which they were
deleted---not be re-created in their original
pre-rematerialization order. While this does not impact correctness
(i.e., use-def relations are always honored), this goes against the
rollbacker's intent to re-create the MIR exactly as it was
pre-rematerializations (up to slot index changes).

  Commit: 69e176310e4f746089e3dee91b8698555af5a3e5
      https://github.com/llvm/llvm-project/commit/69e176310e4f746089e3dee91b8698555af5a3e5
  Author: Lucas Ramirez <lucas.rami at proton.me>
  Date:   2026-06-08 (Mon, 08 Jun 2026)

  Changed paths:
    M llvm/include/llvm/CodeGen/Rematerializer.h
    M llvm/lib/CodeGen/Rematerializer.cpp
    M llvm/unittests/CodeGen/RematerializerTest.cpp

  Log Message:
  -----------
  Change rollback method to reduce tracking need

  Commit: c026830c906ae0c4cb8313107f4b75905808744f
      https://github.com/llvm/llvm-project/commit/c026830c906ae0c4cb8313107f4b75905808744f
  Author: Lucas Ramirez <lucas.rami at proton.me>
  Date:   2026-06-08 (Mon, 08 Jun 2026)

  Changed paths:
    M llvm/include/llvm/CodeGen/Rematerializer.h
    M llvm/lib/CodeGen/Rematerializer.cpp
    M llvm/lib/Target/AMDGPU/GCNSchedStrategy.cpp
    M llvm/unittests/CodeGen/RematerializerTest.cpp

  Log Message:
  -----------
  [CodeGen][AMDGPU] Prepare rematerializer for subreg remat support (NFC)

This makes some NFCs to the rematerializer before starting to improve
support for sub-register rematerialization. The main changes are the
replacement of `Rematerializer::Reg::Dependency` type (essentially a
pair of a machine operand index and a register index) in favor of a
simple register index, dropping the machine operand index. The latter
has no current uses and will lose meaning once we allow rematerializable
registers to be defined by multiple MIs. Similarly, and for the same
rationale, unrematerializable register dependencies are now tracked as
a register/lanemask pair instead of a machine operand index.

Other minor changes listed below.

- Removal of `DefRegion` argument to `Rematerializer::recreteReg`.
  Registers are always re-created in their original region so there is
  no need to set their region again.
- Removal of `InsertPos` unused argument to
  `Rematerializer::postRematerialization`.
- Refactor of how AMDGPU's scheduler checks whether a given register is
  rematerializable. This will make the future functional change for
  subreg support minimal.

  Commit: 46d4a2095df1fd30ca5573ba8cb1266b8696a4f9
      https://github.com/llvm/llvm-project/commit/46d4a2095df1fd30ca5573ba8cb1266b8696a4f9
  Author: Lucas Ramirez <lucas.rami at proton.me>
  Date:   2026-06-09 (Tue, 09 Jun 2026)

  Changed paths:
    M llvm/include/llvm/CodeGen/Rematerializer.h
    M llvm/lib/CodeGen/Rematerializer.cpp
    M llvm/test/CodeGen/AMDGPU/machine-scheduler-sink-trivial-remats.mir
    M llvm/unittests/CodeGen/RematerializerTest.cpp

  Log Message:
  -----------
  [CodeGen] Fine-grained LIS updates on remat and dead-def handling

This replaces the rematerializer's manual bulk LIS update paradigm in
favor of an automated fine-grained one that

1. performs LIS updates as rematerializations happen and
2. handles the removal of dead-definitions properly (this replaces the
   prior partial handling of live interval splitting).

The new approach should be less error-prone (clients do not have to
periodically update the LIS, which is now up-to-date at all times from
the clients's perspective) and faster in general (live intervals aren't
fully re-created every time a def or use of a register changes).

Handling dead-definitions (through a `LiveRangeEditor`) adds some
complexity to the rematerializer since unrematerializable MIs can now
also be deleted. This is exposed to listeners through a new event.
Furthermore, rematerializable registers can now become "permanently
dead" if all their users were unrematerializable MIs that became dead as
a result of other rematerializations.

The combination of these two improvements makes handling live-interval
splitting unnecessary. Rematerializable registers have a single-def by
construction so cannot ever have multiple disconnected components. On
the other hand, if we remove dead definitions as they appear,
unreamaterializable registers's live interval cannot become made up of
multiple disconnected components purely as a result of
rematerializations. It is the rematerializer's client responsibility to
ensure that the LIS is in a valid state before the rematerializer
analyses the function.

Compare: https://github.com/llvm/llvm-project/compare/ce9af23750fe%5E...46d4a2095df1

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