[qt/clang/llvm-project]: Summary of bulk changes made

Git repository change summary for qt/clang/llvm-project
Pushed by mirror-service into branch 'upstream/users/momchil-velikov/gvn-simple-gvn-hoist-scalars'.
Changed from 0000000000000000000000000000000000000000 to 9d7161d7eb6d82fa4564428d0a0bbccd356d2a2d
Acknowledgement was received that this change introduces only existing code that has been pushed to another public open source repository.

This change contains the following new commits:

Git commit e1784a875479f2bb3fd139c7fff75393a3b91dc5 by Momchil Velikov on 15/07/2026 at 15:57..
[GVN] Remove the "private" `llvm::gvn` namespace (NFC)

Move `AvailableValue` and `AvailableValueInBlock` into GVNPass, similar
to other helper types.

Retain `llvm::gvn::GVNLegacyPass` as just `llvm::GVNLegacyPass` -
"legacy" is already a sufficent hint and it is not going to become more
"private" by stacking "gvn" prefixes to the name.

Ideally, `GVNLegacyPass` should be defined in an anonymous namespace, but
that is not possible because it is declared as a friend of GVNPass.
https://invent.kde.org/qt/clang/llvm-project/-/commit/e1784a875479f2bb3fd139c7fff75393a3b91dc5

Git commit 2293acff88a03097a610c682769ad316d6b1fc0e by Momchil Velikov on 15/07/2026 at 15:57..
[GVN] Rename some functions to follow LLVM naming conventions (NFC)
https://invent.kde.org/qt/clang/llvm-project/-/commit/2293acff88a03097a610c682769ad316d6b1fc0e

Git commit 67ad2e492b9f7a5ead697bfd8ec1e21aef2973cf by Momchil Velikov on 15/07/2026 at 15:57..
[GVN] Remove unused debug helper (NFC)

The `GVNPass::dump` method is not used anywhere. Moreover, there's
no `GVNPass` state that corresponds to its parameter type. Even if a
`GVNPass::dump` method could be useful, this one wasn't it.
https://invent.kde.org/qt/clang/llvm-project/-/commit/67ad2e492b9f7a5ead697bfd8ec1e21aef2973cf

Git commit 29556c748d9f533bb8bdf1a98f3bf279ebedaddb by Momchil Velikov on 15/07/2026 at 16:02..
[GVN] Reorganise GVN.h/GVH.cpp to improve readability and maintainability (NFC)

Over the years GVN.h/GVN.cpp has grown in size and complexity, and the order of
member functions and definitions has become somewhat arbitrary. This commit
reorganises the code to improve readability and maintainability.

* in `GVNPass` class, put private member variables first, followed by public
  member functions, and then private member functions
* in `GVNPass` class: private type definitions are placed in front of the
  logically related member variables (except `ValueTable` which need to be
  public)
* definitions of `GVNPass::ValueTable` methods are grouped and reordered to
  match the order of their declarations
* The following `GVNPass` member functions were made `private` and `LLVM_API`
  removed: `getDominatorTree`, `getAliasAnalysis`, `getMemDep`,
  `isScalarPREEnabled`, `isLoadPREEnabled`, `isLoadInLoopPREEnabled`,
  `isLoadPRESplitBackedgeEnabled`,  `isMemDepEnabled`,  `isMemorySSAEnabled`,
  and `salvageAndRemoveInstruction`
* `constructSSAForLoadSet` changed to take a `Dominator &`, in order to not
  require access to the (now) private `getDominatorTree`
* member functions of `GVNPass` rearranged into a more logical order:
  - starting with the main pass entry pount (`runImpl`) put utility member
  functions in front of their callers, in order of calling (where it matters),
  for example `runImpl` -> `iterateOnFunction` -> `perfromPRE`
  - group functions of the same "theme" together, for example
  `iterateOnFunction` +  `processBlock` +  `processInstrution`, or another
  example, `performLoadPRE` + `performLoopLoadPRE`
  - put miscelaneous helper member functions at the end
* rearrange definitions in `GVN.cpp` to match the order of declarations in
  `GVN.h`
* place `static` helper functions close and in front of their callers
https://invent.kde.org/qt/clang/llvm-project/-/commit/29556c748d9f533bb8bdf1a98f3bf279ebedaddb

Git commit ee5c81489e276d8c6f5c8d8b2ae281b8939c94c0 by Momchil Velikov on 15/07/2026 at 16:02..
[GVN] Assign unique VNs to calls with operand bundles

Call instructions with operand bundles may be assigned the same value number,
even if operand bundles differ. The GVN may eliminate one of the calls in favour
of another and drop one of the operand bundles.

Work around this by assigning unique value numbers to calls with operand
bundles.
https://invent.kde.org/qt/clang/llvm-project/-/commit/ee5c81489e276d8c6f5c8d8b2ae281b8939c94c0

Git commit 12654f87243c8ec685d68442622bfd3e87e51873 by Momchil Velikov on 15/07/2026 at 16:02..
[GVN] Simple GVN-based hoisting of scalars: precommit tests
https://invent.kde.org/qt/clang/llvm-project/-/commit/12654f87243c8ec685d68442622bfd3e87e51873

Git commit 9d7161d7eb6d82fa4564428d0a0bbccd356d2a2d by Momchil Velikov on 15/07/2026 at 16:02..
[GVN] Simple GVN-based hoisring of scalars

RFC/discussion: https://lists.llvm.org/pipermail/llvm-dev/2021-September/152665.html

This patch is a update of https://reviews.llvm.org/D110817

This patch implements simple hoisting of instructions from two
single-predecessor blocks to their common predecessor, as a subroutine
in the GVN pass.

The patch pairs two instructions (A and B) with the same value number,
moves A to the predecessor block, replaces all uses of B with A, and
deletes B.

Outline of the algorithm follows:

Scan the then-block to collect hoist candidates ("then-" and "else-"
prefixes are purely naming and have no connection to the condition in
the predecessor block)

Scan the else-block for hoist candidates, that match some already
selected instruction from the then-block.

During both scans, instructions which are not guaranteed to transfer
control to the following instruction act as "hoist barriers" - after we
encounter such an instruction, we select for potential hoisting/merge
only instructions, which are safe to execute speculatively. Also
instructions which read/write memory are not considered for hoisting,
subject for a follow-up patch. The hoist barriers can itself be hoisted,
opening opportunities for other instructions. For each hoist candidate
pair, the immediately preceding hoist barriers from then- and
else-blocks are recorded as prerequisites for hoisting the pair.

Next we try hoist to hoist each candidate pair. We begin by trying to
hoist dependencies of the then-instruction, which would be its
immediately preceding hoist barrier and its operands. Each of these
dependencies must already be in a dominating block or is itself paired
with an instruction from the else-block. If we cannot hoist an
dependency for whatever reason, the we stop trying to hoist the pair.

Now that all the operands of the then-instruction are in a dominating
block, we check the barriers/operands of the else-instruction. They all
must already be in a dominating block, either initially or as a result
of hoisting barriers/operands of the then-instruction. If any dependency
is still in the else-block, we stop trying to hoist the pair.

As a last step, we move the then-instruction to the predecessor block
and delete the else-instruction.
https://invent.kde.org/qt/clang/llvm-project/-/commit/9d7161d7eb6d82fa4564428d0a0bbccd356d2a2d