[CodeGen] Avoid repeated hash lookups (NFC) (#110074)

[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] Use *{Set,Map}::contains (NFC)

[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 ...

[MIRVRegNamer] Avoid opcode hash collision

D121929 happens to cause CodeGen/MIR/AArch64/mirnamer.mir to fail due
to a hash collision caused by adding two extra opcodes. The collision
is only in the

[MIRVRegNamer] Avoid opcode hash collision

D121929 happens to cause CodeGen/MIR/AArch64/mirnamer.mir to fail due
to a hash collision caused by adding two extra opcodes. The collision
is only in the top 19 bits of the hashed opcode so fix this by just
using the whole hash (in fixed width hex for consistency) instead of
the top 5 decimal digits.

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

show more ...

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

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 ...

[MIRVRegNamer] Experimental MachineInstr stable hashing (Fowler-Noll-Vo)

This hashing scheme has been useful out of tree, and I want to start
experimenting with it. Specifically I want to experiment

[MIRVRegNamer] Experimental MachineInstr stable hashing (Fowler-Noll-Vo)

This hashing scheme has been useful out of tree, and I want to start
experimenting with it. Specifically I want to experiment on the
MIRVRegNamer, MIRCanononicalizer, and eventually the MachineOutliner.

This diff is a first step, that optionally brings stable hashing to the
MIRVRegNamer (and as a result, the MIRCanonicalizer). We've tested this
hashing scheme on a lot of MachineOperand types that llvm::hash_value
can not handle in a stable manner.

This stable hashing was also the basis for

"Global Machine Outliner for ThinLTO" in EuroLLVM 2020

http://llvm.org/devmtg/2020-04/talks.html#TechTalk_58

Credits: Kyungwoo Lee, Nikolai Tillmann

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

show more ...

[llvm][MIRVRegNamer] Avoid collisions across jump table indices.

Hash Jump Table Indices uniquely within a basic block for MIR
Canonicalizer / MIR VReg Renamer passes.

Differential Revision: https:

[llvm][MIRVRegNamer] Avoid collisions across jump table indices.

Hash Jump Table Indices uniquely within a basic block for MIR
Canonicalizer / MIR VReg Renamer passes.

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

show more ...

MIRVRegNamerUtils.h - remove unnecessary includes. NFC.
Replace with forward declarations or push down to MIRVRegNamerUtils.cpp where necessary.

[Alignment][NFC] MachineMemOperand::getAlign/getBaseAlign

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm

[Alignment][NFC] MachineMemOperand::getAlign/getBaseAlign

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: arsenm, dschuff, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, hiraditya, aheejin, kbarton, jrtc27, atanasyan, jfb, kerbowa, llvm-commits

Tags: #llvm

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

show more ...

[llvm][MIRVRegNamer] Avoid collisions across constant pool indices.

When hashing on MachineOperand::MO_ConstantPoolIndex, now MIR-Canon and
MIRVRegNamer will no longer result in a hash collision.

D

[llvm][MIRVRegNamer] Avoid collisions across constant pool indices.

When hashing on MachineOperand::MO_ConstantPoolIndex, now MIR-Canon and
MIRVRegNamer will no longer result in a hash collision.

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

show more ...

[llvm][MIRVRegNamerUtils] Adding hashing on FrameIndex MachineOperands.

This patch makes it so that cases where multiple instructions that differ only
in their FrameIndex MachineOperand values no lo

[llvm][MIRVRegNamerUtils] Adding hashing on FrameIndex MachineOperands.

This patch makes it so that cases where multiple instructions that differ only
in their FrameIndex MachineOperand values no longer collide. For instance:

%1:_(p0) = G_FRAME_INDEX %stack.0
%2:_(p0) = G_FRAME_INDEX %stack.1

Prior to this patch these instructions would collide together.

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

show more ...

[NFC][llvm][MIRVRegNamerUtils] Moving some switch cases and altering comments.

[llvm][MIRVRegNamerUtils] Adding hashing on CImm / FPImm MachineOperands.

This patch makes it so that cases where multiple instructions that
differ only in their ConstantInt or ConstantFP MachineOpe

[llvm][MIRVRegNamerUtils] Adding hashing on CImm / FPImm MachineOperands.

This patch makes it so that cases where multiple instructions that
differ only in their ConstantInt or ConstantFP MachineOperand values no
longer collide. For instance:

%0:_(s1) = G_CONSTANT i1 true
%1:_(s1) = G_CONSTANT i1 false
%2:_(s32) = G_FCONSTANT float 1.0
%3:_(s32) = G_FCONSTANT float 0.0

Prior to this patch the first two instructions would collide together.
Also, the last two G_FCONSTANT instructions would also collide. Now they
will no longer collide.

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

show more ...

[NFC][llvm][MIRVRegNamerUtils] Refactoring GetHashableMO into switch-statement.

This refactors the if-statements handling the hashing of various
MachineOperand types into a switch-statement. The pur

[NFC][llvm][MIRVRegNamerUtils] Refactoring GetHashableMO into switch-statement.

This refactors the if-statements handling the hashing of various
MachineOperand types into a switch-statement. The purpose is to cover
all the basis for all MachineOperand types while being very deliberate
about which MachineOperand types we are not handling and why (better
added comments). This patch is a NFC redo of https://reviews.llvm.org/D71396.
Much of the changes present in D71396 will come in smaller follow-up patches
that will add support for hashing the MachineOperand types that aren't
covered piece-meal with tests for each new case.

show more ...

[NFC][llvm][MIRVRegNamerUtils] Moving methods around. Making some private.

Making all externally unused methods private in MIRVRegNamerUtils.h.
Moving or deleting a couple other methods around.

[llvm][MIRVRegNamerUtils] Adding hashing on memoperands.

No more hash collisions for memoperands. Now the MIRCanonicalization
pass shouldn't hit hash collisions when dealing with nearly identical
me

[llvm][MIRVRegNamerUtils] Adding hashing on memoperands.

No more hash collisions for memoperands. Now the MIRCanonicalization
pass shouldn't hit hash collisions when dealing with nearly identical
memory accessing instructions when their memoperands are in fact different.

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

show more ...

[llvm][MIRVRegNamerUtil] Adding hashing against MachineInstr flags.

Now, flags will result in differing hashes for a given MI. In effect, if
you have two instructions with everything identical excep

[llvm][MIRVRegNamerUtil] Adding hashing against MachineInstr flags.

Now, flags will result in differing hashes for a given MI. In effect, if
you have two instructions with everything identical except for their
flags then you should get two different hashes and fewer collisions.

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

show more ...

[NFCi][llvm][MIRVRegNamerUtils] Making some code cleanup and stylistic changes.

Making some changes to MIRVRegNamerUtils.cpp to use some more modern c++
features as well as some changes to generally

[NFCi][llvm][MIRVRegNamerUtils] Making some code cleanup and stylistic changes.

Making some changes to MIRVRegNamerUtils.cpp to use some more modern c++
features as well as some changes to generally make the code more concise
and more understandable.

I make this an NFCi because in one case I drop the whole
"if (!MO->isDef()) MO->setIsKill(false);" thing that was added in the
original implementation, generally because I don't think this is really
semantically sound. I also changed up the implementation of
VRegRenamer::createVirtualRegisterWithLowerName somewhat because I am
now lower-casing the name unconditionally because I confirmed that that
was in fact aditya_nandakumar@apple.com's intent.

In all other cases, behavior should not be changed.

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

show more ...

[MirNamer][Canonicalizer]: Perform instruction semantic based renaming

https://reviews.llvm.org/D70210

Previously:

Due to sensitivity of the algorithm with gaps, and extra instructions,
when diffi

[MirNamer][Canonicalizer]: Perform instruction semantic based renaming

https://reviews.llvm.org/D70210

Previously:

Due to sensitivity of the algorithm with gaps, and extra instructions,
when diffing, often we see naming being off by a few. Makes the diff
unreadable even for tests with 7 and 8 instructions respectively.
Naming can change depending on candidates (and order of picking
candidates). Suddenly if there's one extra instruction somewhere, the
entire subtree would be named completely differently.
No consistent naming of similar instructions which occur in different
functions. If we try to do something like count the frequency
distribution of various differences across suite, then the above
sensitivity issues are going to result in poor results.
Instead:

Name instruction based on semantics of the instruction (hash of the
opcode and operands). Essentially for a given instruction that occurs in
any module/function it'll be named similarly (ie semantic). This has
some nice properties
Can easily look at many instructions and just check the hash and if
they're named similarly, then it's the same instruction. Makes it very
easy to spot the same instruction both multiple times, as well as across
many functions (useful for frequency distribution).
Independent of traversal/candidates/depth of graph. No need to keep
track of last index/gaps/skip count etc.
No off by few issues with diffs. I've tried the old vs new
implementation in files ranging from 30 to 700 instructions. In both
cases with the old algorithm, diffs are a sea of red, where as for the
semantic version, in both cases, the diffs line up beautifully.
Simplified implementation of the main loop (simple iteration) , no keep
track of what's visited and not.
Handle collision just by incrementing a counter. Roughly
bb[N]_hash_[CollisionCount].
Additionally with the new implementation, we can probably avoid doing
the hoisting of instructions to various places, as they'll likely be
named the same resulting in differences only based on collision (ie
regardless of whether the instruction is hoisted or not/close to use or
not, it'll be named the same hash which should result in use of the
instruction be identical with the only change being the collision count)
which is very easy to spot visually.

show more ...

Prune two MachineInstr.h includes, fix up deps

MachineInstr.h included AliasAnalysis.h, which includes a world of IR
constructs mostly unneeded in CodeGen. Prune it. Same for
DebugInfoMetadata.h.

N

Prune two MachineInstr.h includes, fix up deps

MachineInstr.h included AliasAnalysis.h, which includes a world of IR
constructs mostly unneeded in CodeGen. Prune it. Same for
DebugInfoMetadata.h.

Noticed with -ftime-trace.

llvm-svn: 375311

show more ...