[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-op-bundle-uniq-vn'.
Changed from 0000000000000000000000000000000000000000 to ee5c81489e276d8c6f5c8d8b2ae281b8939c94c0
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