Use llvm::less_first and llvm::less_second (NFC)

[CodeGen] Remove a redundant void (NFC)

Identified with modernize-redundant-void-arg.

Use llvm::sort instead of std::sort where possible

llvm::sort is beneficial even when we use the iterator-based overload,
since it can optionally shuffle the elements (to detect
non-determinism). Ho

Use llvm::sort instead of std::sort where possible

llvm::sort is beneficial even when we use the iterator-based overload,
since it can optionally shuffle the elements (to detect
non-determinism). However llvm::sort is not usable everywhere, for
example, in compiler-rt.

Reviewed By: nhaehnle

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

show more ...

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

[DebugInfo][InstrRef] Fix error in copy handling in InstrRefLDV

Currently, an error exists when InstrRefBasedLDV observes transfers of
variables across copies, which causes it to lose track of varia

[DebugInfo][InstrRef] Fix error in copy handling in InstrRefLDV

Currently, an error exists when InstrRefBasedLDV observes transfers of
variables across copies, which causes it to lose track of variables
under certain circumstances, resulting in shorter lifetimes for those
variables as LDV gives up searching for live locations for them. This
patch fixes this issue by storing the currently tracked values in
the destination first, then updating them manually later without
clobbering or assigning them the wrong value.

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

show more ...

[CodeGen] Init EmptyExpr before the first use

[DebugInfo][InstrRef] Describe value sizes when spilt to stack

This is a re-apply of D123599, which was reverted in 4fe2ab5279408, now
with a more appropriate assertion. Original commit message foll

[DebugInfo][InstrRef] Describe value sizes when spilt to stack

This is a re-apply of D123599, which was reverted in 4fe2ab5279408, now
with a more appropriate assertion. Original commit message follow:

InstrRefBasedLDV can track and describe variable values that are spilt to
the stack -- however it does not current describe the size of the value on
the stack. This can cause uninitialized bytes to be read from the stack if
a small register is spilt for a larger variable, or theoretically on
big-endian machines if a large value on the stack is used for a small
variable.

Fix this by using DW_OP_deref_size to specify the amount of data to load
from the stack, if there's any possibility for ambiguity. There are a few
scenarios where this can be omitted (such as when using DW_OP_piece and a
non-DW_OP_stack_value location), see deref-spills-with-size.mir for an
explicit table of inputs flavours and output expressions.

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

show more ...

Revert "[DebugInfo][InstrRef] Describe value sizes when spilt to stack"

This reverts commit a15b66e76d1ecff625a4bbb4a46ff83a43138f49.

This causes linker to crash at assertion: `Assertion failed: !E

Revert "[DebugInfo][InstrRef] Describe value sizes when spilt to stack"

This reverts commit a15b66e76d1ecff625a4bbb4a46ff83a43138f49.

This causes linker to crash at assertion: `Assertion failed: !Expr->isComplex(), file C:\b\s\w\ir\cache\builder\src\third_party\llvm\llvm\lib\CodeGen\LiveDebugValues\InstrRefBasedImpl.cpp, line 907`.

show more ...

[DebugInfo][InstrRef] Describe value sizes when spilt to stack

InstrRefBasedLDV can track and describe variable values that are spilt to
the stack -- however it does not current describe the size of

[DebugInfo][InstrRef] Describe value sizes when spilt to stack

InstrRefBasedLDV can track and describe variable values that are spilt to
the stack -- however it does not current describe the size of the value on
the stack. This can cause uninitialized bytes to be read from the stack if
a small register is spilt for a larger variable, or theoretically on
big-endian machines if a large value on the stack is used for a small
variable.

Fix this by using DW_OP_deref_size to specify the amount of data to load
from the stack, if there's any possibility for ambiguity. There are a few
scenarios where this can be omitted (such as when using DW_OP_piece and a
non-DW_OP_stack_value location), see deref-spills-with-size.mir for an
explicit table of inputs flavours and output expressions.

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

show more ...

Reapply D124184, [DebugInfo][InstrRef] Add a size operand to DBG_PHI

This was reverted twice, in 987cd7c3ed75b and 13815e8cbf8d4. The latter
stemed from not accounting for rare register classes in a

Reapply D124184, [DebugInfo][InstrRef] Add a size operand to DBG_PHI

This was reverted twice, in 987cd7c3ed75b and 13815e8cbf8d4. The latter
stemed from not accounting for rare register classes in a pre-allocated
array, and the former from an array not being completely initialized,
leading to asan complaining.

show more ...

Revert "Reapply D124184, [DebugInfo][InstrRef] Add a size operand to DBG_PHI"

This reverts commit 5db925023169f8a19419e68153682d1e518f8392.

Further to the early revert, the sanitizers have found so

Revert "Reapply D124184, [DebugInfo][InstrRef] Add a size operand to DBG_PHI"

This reverts commit 5db925023169f8a19419e68153682d1e518f8392.

Further to the early revert, the sanitizers have found something wrong with
this.

show more ...

Reapply D124184, [DebugInfo][InstrRef] Add a size operand to DBG_PHI

This was applied in fda4305e53784, reverted in 13815e8cbf8d49, the problem
was that fp80 X86 registers that were spilt to the sta

Reapply D124184, [DebugInfo][InstrRef] Add a size operand to DBG_PHI

This was applied in fda4305e53784, reverted in 13815e8cbf8d49, the problem
was that fp80 X86 registers that were spilt to the stack aren't expected by
LiveDebugValues. It pre-allocates a position number for all register sizes
that can be spilt, and 80 bits isn't exactly common.

The solution is to scan the register classes to find any unrecognised
register sizes, adn pre-allocate those position numbers, avoiding a later
assertion.

show more ...

Revert "[DebugInfo][InstrRef] Add a size operand to DBG_PHI"

This reverts commit fda4305e5378478051be225248bfe9c1d401d938.

Green dragon has spotted a problem -- it's understood, but might be fiddly

Revert "[DebugInfo][InstrRef] Add a size operand to DBG_PHI"

This reverts commit fda4305e5378478051be225248bfe9c1d401d938.

Green dragon has spotted a problem -- it's understood, but might be fiddly
to fix, reverting in the meantime.

show more ...

[DebugInfo][InstrRef] Add a size operand to DBG_PHI

DBG_PHI instructions can refer to stack slots, to indicate that multiple
values merge together on control flow joins in that slot. This is fine --

[DebugInfo][InstrRef] Add a size operand to DBG_PHI

DBG_PHI instructions can refer to stack slots, to indicate that multiple
values merge together on control flow joins in that slot. This is fine --
however the slot might be merged at a later date with a slot of a different
size. In doing so, we lose information about the size the eliminated PHI.
Later analysis passes have to guess.

Improve this by attaching an optional "bit size" operand to DBG_PHI, which
only gets added for stack slots, to let us know how large a size the value
on the stack is.

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

show more ...

[DebugInfo][InstrRef] Prefer stack locations for variables

This patch adjusts what location is picked for a known variable value --
preferring to leave locations on the stack, even when a value is r

[DebugInfo][InstrRef] Prefer stack locations for variables

This patch adjusts what location is picked for a known variable value --
preferring to leave locations on the stack, even when a value is re-loaded
into a register. The benefit is reduced location list entropy, on a
clang-3.4 build I found that .debug_loclists reduces in size by 6%, from
29Mb down to 27Mb.

Testing: a few tests need the stack slot to be written to explicitly, to
force LiveDebugValues into restoring the variable location to a register.
I've added an explicit test for the desired behaviour in
livedebugvalues_recover_clobbers.mir .

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

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

[DebugInfo][InstrRef][NFC] Use unique_ptr instead of raw pointers

InstrRefBasedLDV allocates some big tables of ValueIDNum, to store live-in
and live-out block values in, that then get passed around

[DebugInfo][InstrRef][NFC] Use unique_ptr instead of raw pointers

InstrRefBasedLDV allocates some big tables of ValueIDNum, to store live-in
and live-out block values in, that then get passed around as pointers
everywhere. This patch wraps the allocation in a std::unique_ptr, names
some types based on unique_ptr, and passes references to those around
instead. There's no functional change, but it makes it clearer to the
reader that references to these tables are borrowed rather than owned, and
we get some extra validity assertions too.

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

show more ...

[DebugInfo][InstrRef] Don't fire assertions if debug-info is faulty

It's inevitable that optimisation passes will fail to update debug-info:
when that happens, it's best if the compiler doesn't cras

[DebugInfo][InstrRef] Don't fire assertions if debug-info is faulty

It's inevitable that optimisation passes will fail to update debug-info:
when that happens, it's best if the compiler doesn't crash as a result.
Therefore, downgrade a few assertions / failure modes that would crash
when illegal debug-info was seen, to instead drop variable locations. In
practice this means that an instruction reference to a nonexistant or
illegal operand should be tolerated.

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

show more ...

[CodeGen] Use = default (NFC)

Identified with modernize-use-equals-default

Follow up to 6e03a68b776dc, squelch another leak

This patch is a sticking-paster until D118774 solves the situation with
unique_ptrs. I'm certainly wishing I'd focused on that first X_X.

Follow up to 9fd9d56dc6b, avoid a memory leak

Gaps in the basic block number range (from blocks being deleted or folded)
get block-value-tables allocated but never ejected, leading to a memory
leak,

Follow up to 9fd9d56dc6b, avoid a memory leak

Gaps in the basic block number range (from blocks being deleted or folded)
get block-value-tables allocated but never ejected, leading to a memory
leak, currently tripping up the asan buildbots. Fix this up by manually
freeing that memory.

As suggested elsewhere, if these things were owned by a unique_ptr then
cleanup would happen automagically. D118774 should eliminate the need for
this dance.

show more ...

[DebugInfo][InstrRef] Fix a tombstone-in-DenseMap crash from D117877

This is a follow-up to D117877: variable assignments of DBG_VALUE $noreg,
or DBG_INSTR_REFs where no value can be found, are repr

[DebugInfo][InstrRef] Fix a tombstone-in-DenseMap crash from D117877

This is a follow-up to D117877: variable assignments of DBG_VALUE $noreg,
or DBG_INSTR_REFs where no value can be found, are represented by a
DbgValue object with Kind "Undef", explicitly meaning "there is no value".
In D117877 I added a special-case to some assignment accounting faster,
without considering this scenario. It causes variables to be given the
value ValueIDNum::EmptyValue, which then ends up being a DenseMap key. The
DenseMap asserts, because EmptyValue is the tombstone key.

Fix this by handling the assign-undef scenario in the special case, to
match what happens in the general case: the variable has no value if it's
only ever assigned $noreg / undef.

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

show more ...

[DebugInfo][InstrRef][NFC] Use depth-first scope search for variable locs

This patch aims to reduce max-rss from instruction referencing, by avoiding
keeping variable value information in memory for

[DebugInfo][InstrRef][NFC] Use depth-first scope search for variable locs

This patch aims to reduce max-rss from instruction referencing, by avoiding
keeping variable value information in memory for too long. Instead of
computing all the variable values then emitting them to DBG_VALUE
instructions, this patch tries to stream the information out through a
depth first search:
* Make use of the fact LexicalScopes gives a depth-number to each lexical
scope,
* Produce a map that identifies the last lexical scope to make use of a
block,
* Enumerate each scope in LexicalScopes' DFS order, solving the variable
value problem,
* After each scope is processed, look for any blocks that won't be used by
any other scope, and emit all the variable information to DBG_VALUE
instructions.

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

show more ...