Reapply "[StructuralHash] Global Variable (#118412)"

This reverts commit 6a0d6fc2e92bcfb7cb01a4c6cdd751a9b4b4c159.

Revert "[StructuralHash] Global Variable (#118412)"

This reverts commit 1afb81dfaf902c1c42bd91fec1a7385e6e1529d3.

[StructuralHash] Global Variable (#118412)

This update enhances the implementation of structural hashing for global
variables, using their initial contents. Private global variables or
constants a

[StructuralHash] Global Variable (#118412)

This update enhances the implementation of structural hashing for global
variables, using their initial contents. Private global variables or
constants are often used for metadata, where their names are not unique.
This can lead to the creation of different hash results although they
could be merged by the linker as they are effectively identical.
- Refine the hashing of GlobalVariables for strings or certain
Objective-C metadata cases that have section names. This can be further
extended to other scenarios.
- Expose StructuralHash for GlobalVariable so that this API can be
utilized by MachineStableHashing, which is also employed in the global
function outliner.

This change significantly improves size reduction by an additional 1% on
the LLD binary when the global function outliner and merger are enabled
together. As discussed in the RFC
https://discourse.llvm.org/t/loh-conflicting-with-machineoutliner/83279/8?u=kyulee-com,
if we disable or relocate the LOH pass, the size impact could increase
to 4%.

show more ...

[CodeGen] Remove unused includes (NFC) (#115996)

Identified with misc-include-cleaner.

[StableHash] Implement stable global name for the hash computation (#106156)

LLVM often extends global names by adding suffixes to distinguish unique
identities. However, these suffixes are not alw

[StableHash] Implement stable global name for the hash computation (#106156)

LLVM often extends global names by adding suffixes to distinguish unique
identities. However, these suffixes are not always stable across
different runs and build environments. To address this issue, I
implemented `get_stable_name` to ignore such suffixes and obtain the
original name. This approach is not new, as PGO or Bolt already handle
this issue similarly. Using the stable name obtained from
`get_stable_name`, I implemented `stable_hash_name` while utilizing the
same underlying `xxh3_64bit` algorithm as before.

show more ...

[StableHash] Implement with xxh3_64bits (#105849)

This is a follow-up to address a suggestion from
https://github.com/llvm/llvm-project/pull/105619.
The main goal of this change is to efficiently

[StableHash] Implement with xxh3_64bits (#105849)

This is a follow-up to address a suggestion from
https://github.com/llvm/llvm-project/pull/105619.
The main goal of this change is to efficiently implement stable hash
functions using the xxh3 64bits API.
`stable_hash_combine_range` and `stable_hash_combine_array` functions
are removed and consolidated into a more general `stable_hash_combine`
function that takes an `ArrayRef<stable_hash>` as input.

show more ...

[NFC] Use stable_hash_combine instead of hash_combine (#105619)

I found the current stable hash is not deterministic across multiple
runs on a specific platform. This is because it uses `hash_combi

[NFC] Use stable_hash_combine instead of hash_combine (#105619)

I found the current stable hash is not deterministic across multiple
runs on a specific platform. This is because it uses `hash_combine`
instead of `stable_hash_combine`.

show more ...

[ADT,CodeGen] Remove stable_hash_combine_string

FNV, used by stable_hash_combine_string is extremely slow. For string
hashing with good avalanche effects, we prefer xxh3_64bits.

StableHashing.h mig

[ADT,CodeGen] Remove stable_hash_combine_string

FNV, used by stable_hash_combine_string is extremely slow. For string
hashing with good avalanche effects, we prefer xxh3_64bits.

StableHashing.h might still be useful as it provides a stable
hash_combine while Hashing.h's might be non-deterministic (#96282).

Pull Request: https://github.com/llvm/llvm-project/pull/100668

show more ...

[CodeGen] Use LocationSize for MMO getSize (#84751)

This is part of #70452 that changes the type used for the external
interface of MMO to LocationSize as opposed to uint64_t. This means the
const

[CodeGen] Use LocationSize for MMO getSize (#84751)

This is part of #70452 that changes the type used for the external
interface of MMO to LocationSize as opposed to uint64_t. This means the
constructors take LocationSize, and convert ~UINT64_C(0) to
LocationSize::beforeOrAfter(). The getSize methods return a
LocationSize.

This allows us to be more precise with unknown sizes, not accidentally
treating them as unsigned values, and in the future should allow us to
add proper scalable vector support but none of that is included in this
patch. It should mostly be an NFC.

Global ISel is still expected to use the underlying LLT as it needs, and
are not expected to see unknown sizes for generic operations. Most of
the changes are hopefully fairly mechanical, adding a lot of getValue()
calls and protecting them with hasValue() where needed.

show more ...

[CodeGen] Remove unnecessary includes (NFC)

[llvm] Stop including llvm/ADT/DenseMapInfo.h (NFC)

Identified with clangd.

[llvm] Stop including llvm/ADT/iterator_range.h (NFC)

Identified with misc-include-cleaner.

[NFC] Move StableHashing.h from CodeGen to ADT (#67704)

[CodeGen] Remove uses of Register::isPhysicalRegister/isVirtualRegister. NFC

Use isPhysical/isVirtual methods.

Reviewed By: foad

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

[DebugInfo][NFC] Add new MachineOperand type and change DBG_INSTR_REF syntax

This patch makes two notable changes to the MIR debug info representation,
which result in different MIR output but ident

[DebugInfo][NFC] Add new MachineOperand type and change DBG_INSTR_REF syntax

This patch makes two notable changes to the MIR debug info representation,
which result in different MIR output but identical final DWARF output (NFC
w.r.t. the full compilation). The two changes are:

* The introduction of a new MachineOperand type, MO_DbgInstrRef, which
consists of two unsigned numbers that are used to index an instruction
and an output operand within that instruction, having a meaning
identical to first two operands of the current DBG_INSTR_REF
instruction. This operand is only used in DBG_INSTR_REF (see below).
* A change in syntax for the DBG_INSTR_REF instruction, shuffling the
operands to make it resemble DBG_VALUE_LIST instead of DBG_VALUE,
and replacing the first two operands with a single MO_DbgInstrRef-type
operand.

This patch is the first of a set that will allow DBG_INSTR_REF
instructions to refer to multiple machine locations in the same manner
as DBG_VALUE_LIST.

Reviewed By: jmorse

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

show more ...

Address feedback in https://reviews.llvm.org/D133637

https://reviews.llvm.org/D133637 fixes the problem where we should hash raw content of
register mask instead of the pointer to it.

Fix the same

Address feedback in https://reviews.llvm.org/D133637

https://reviews.llvm.org/D133637 fixes the problem where we should hash raw content of
register mask instead of the pointer to it.

Fix the same issue in `llvm::hash_value()`.

Remove the added API `MachineOperand::getRegMaskSize()` to avoid potential confusion.

Add an assert to emphasize that we probably should hash a machine operand iff it has
associated machine function, but keep the fallback logic in the original change.

Reviewed By: MatzeB

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

show more ...

Bug fix on stable hash calculation for machine operands RegisterMask and RegisterLiveOut

MachineOperand::getRegMask() returns a pointer to register mask. We should hash the raw content of register

Bug fix on stable hash calculation for machine operands RegisterMask and RegisterLiveOut

MachineOperand::getRegMask() returns a pointer to register mask. We should hash the raw content of register mask instead of its pointer.

Reviewed By: kyulee

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

show more ...

[CodeGen] Qualify auto variables in for loops (NFC)

Cleanup codegen includes

This is a (fixed) recommit of https://reviews.llvm.org/D121169

after: 1061034926
before: 1063332844

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-in

Cleanup codegen includes

This is a (fixed) recommit of https://reviews.llvm.org/D121169

after: 1061034926
before: 1063332844

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121681

show more ...

Revert "Cleanup codegen includes"

This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20.
Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang,
and many LLVM tests, see comments on https:/

Revert "Cleanup codegen includes"

This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20.
Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang,
and many LLVM tests, see comments on https://reviews.llvm.org/D121169

show more ...

Cleanup codegen includes

after: 1061034926
before: 1063332844

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

[StableHashing] Hash machine basic blocks and functions

This adds very basic support for hashing MachineBasicBlock
and MachineFunction, for use in MachineFunctionPass to
detect passes that modify th

[StableHashing] Hash machine basic blocks and functions

This adds very basic support for hashing MachineBasicBlock
and MachineFunction, for use in MachineFunctionPass to
detect passes that modify the MachineFunction wrongly.

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

show more ...

[StableHashing] Hash vregs with multiple defs

This allows stableHashValue to be used on Machine IR that is
not in SSA form.

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

Rename MachineMemOperand::getOrdering -> getSuccessOrdering.

Since this method can apply to cmpxchg operations, make sure it's clear
what value we're actually retrieving. This will help ensure we d

Rename MachineMemOperand::getOrdering -> getSuccessOrdering.

Since this method can apply to cmpxchg operations, make sure it's clear
what value we're actually retrieving. This will help ensure we don't
accidentally ignore the failure ordering of cmpxchg in the future.

We could potentially introduce a getOrdering() method on AtomicSDNode
that asserts the operation isn't cmpxchg, but not sure that's
worthwhile.

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

show more ...

MachineStableHash.h - remove MachineInstr.h include. NFC.

Use forward declarations and move the include to MachineStableHash.cpp