#
7f230fee |
| 07-Mar-2022 |
serge-sans-paille <sguelton@redhat.com> |
Cleanup codegen includes
after: 1061034926 before: 1063332844
Differential Revision: https://reviews.llvm.org/D121169
|
Revision tags: llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1 |
|
#
ffe8720a |
| 02-Feb-2022 |
serge-sans-paille <sguelton@redhat.com> |
Reduce dependencies on llvm/BinaryFormat/Dwarf.h
This header is very large (3M Lines once expended) and was included in location where dwarf-specific information were not needed.
More specifically,
Reduce dependencies on llvm/BinaryFormat/Dwarf.h
This header is very large (3M Lines once expended) and was included in location where dwarf-specific information were not needed.
More specifically, this commit suppresses the dependencies on llvm/BinaryFormat/Dwarf.h in two headers: llvm/IR/IRBuilder.h and llvm/IR/DebugInfoMetadata.h. As these headers (esp. the former) are widely used, this has a decent impact on number of preprocessed lines generated during compilation of LLVM, as showcased below.
This is achieved by moving some definitions back to the .cpp file, no performance impact implied[0].
As a consequence of that patch, downstream user may need to manually some extra files:
llvm/IR/IRBuilder.h no longer includes llvm/BinaryFormat/Dwarf.h llvm/IR/DebugInfoMetadata.h no longer includes llvm/BinaryFormat/Dwarf.h
In some situations, codes maybe relying on the fact that llvm/BinaryFormat/Dwarf.h was including llvm/ADT/Triple.h, this hidden dependency now needs to be explicit.
$ clang++ -E -Iinclude -I../llvm/include ../llvm/lib/Transforms/Scalar/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l after: 10978519 before: 11245451
Related Discourse thread: https://llvm.discourse.group/t/include-what-you-use-include-cleanup [0] https://llvm-compile-time-tracker.com/compare.php?from=fa7145dfbf94cb93b1c3e610582c495cb806569b&to=995d3e326ee1d9489145e20762c65465a9caeab4&stat=instructions
Differential Revision: https://reviews.llvm.org/D118781
show more ...
|
Revision tags: llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
#
2aed0813 |
| 07-Jan-2022 |
Kazu Hirata <kazu@google.com> |
[llvm] Use true/false instead of 1/0 (NFC)
Identified with modernize-use-bool-literals.
|
#
f108c7f5 |
| 05-Dec-2021 |
Jack Andersen <jackoalan@gmail.com> |
[GlobalISel] Allow DBG_VALUE to use undefined vregs before LiveDebugValues.
Expanding on D109750.
Since `DBG_VALUE` instructions have final register validity determined in `LDVImpl::handleDebugValu
[GlobalISel] Allow DBG_VALUE to use undefined vregs before LiveDebugValues.
Expanding on D109750.
Since `DBG_VALUE` instructions have final register validity determined in `LDVImpl::handleDebugValue`, there is no apparent reason to immediately prune unused register operands as their defs are erased. Consequently, this renders `MachineInstr::eraseFromParentAndMarkDBGValuesForRemoval` moot; gaining a substantial performance improvement.
The only necessary changes involve making relevant passes consider invalid DBG_VALUE vregs uses as valid.
Reviewed By: MatzeB
Differential Revision: https://reviews.llvm.org/D112852
show more ...
|
#
3aed2822 |
| 04-Dec-2021 |
Kazu Hirata <kazu@google.com> |
[CodeGen] Use range-based for loops (NFC)
|
#
3107081e |
| 25-Nov-2021 |
Jeremy Morse <jeremy.morse@sony.com> |
[DebugInfo][InstrRef] Avoid some quadratic behaviour in LiveDebugVariables
This is a performance patch -- LiveDebugVariables can behave quadratically if a lot of debug instructions are inserted back
[DebugInfo][InstrRef] Avoid some quadratic behaviour in LiveDebugVariables
This is a performance patch -- LiveDebugVariables can behave quadratically if a lot of debug instructions are inserted back into the same place, and we have to repeatedly step-over hte ones we've already inserted.
To get around it, whenever we insert a debug instruction at a slot index, check whether there are more debug instructions to insert at this point, and insert them too. That avoids the repeated lookup and stepping through. It relies on the container for unlinked debug instructions being recorded in-order, which is how LiveDebugVariables currently does it.
Differential Revision: https://reviews.llvm.org/D114587
show more ...
|
Revision tags: llvmorg-13.0.1-rc1 |
|
#
6bdb61c5 |
| 02-Nov-2021 |
Kazu Hirata <kazu@google.com> |
[CodeGen] Use make_early_inc_range (NFC)
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4 |
|
#
4af76434 |
| 17-Sep-2021 |
Simon Pilgrim <llvm-dev@redking.me.uk> |
[CodeGen] LiveDebug - Use const-ref iterator in for-range loop. NFCI.
Avoid unnecessary copies, reported by MSVC static analyzer.
|
Revision tags: llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2 |
|
#
0116ed00 |
| 25-Aug-2021 |
Jeremy Morse <jeremy.morse@sony.com> |
[DebugInfo][InstrRef] Don't use instr-ref for unoptimised functions
InstrRefBasedLDV is marginally slower than VarlocBasedLDV when analysing optimised code -- however, it's much slower when analysin
[DebugInfo][InstrRef] Don't use instr-ref for unoptimised functions
InstrRefBasedLDV is marginally slower than VarlocBasedLDV when analysing optimised code -- however, it's much slower when analysing code compiled -O0.
To avoid this: don't use instruction referencing for -O0 functions. In the "pure" case of unoptimised code, this won't really harm the debugging experience because most variables won't have been promoted off the stack, so can't go missing. It becomes more complicated when optimised code is inlined into functions marked optnone; however these are rare, and as -O0 doesn't run many optimisations there should be little damage to the debug experience as a result.
I've taken the opportunity to refactor testing for instruction-referencing into a MachineFunction method, which seems the most appropriate place to put it.
Differential Revision: https://reviews.llvm.org/D108585
show more ...
|
Revision tags: llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2 |
|
#
63cc251e |
| 02-Jun-2021 |
Jeremy Morse <jeremy.morse@sony.com> |
[DebugInfo][InstrRef][4/4] Support DBG_INSTR_REF through all backend passes
This is a cleanup patch -- we're now able to support all flavours of variable location in instruction referencing mode. Th
[DebugInfo][InstrRef][4/4] Support DBG_INSTR_REF through all backend passes
This is a cleanup patch -- we're now able to support all flavours of variable location in instruction referencing mode. This patch updates various tests for debug instructions to be broader: numerous code paths try to ignore debug isntructions, and they now have to ignore the additional DBG_PHI and DBG_INSTR_REFs that we can generate.
A small amount of rework happens for LiveDebugVariables: as we don't need to track live intervals through regalloc any more, we can get away with unlinking debug instructions before regalloc, then re-inserting them after. Note that this isn't (yet) true of DBG_VALUE_LISTs, they still have to go through live interval tracking.
In SelectionDAG, add a helper lambda that emits half-formed DBG_INSTR_REFs for arguments in instr-ref mode, DBG_VALUE otherwise. This is one of the final locations where DBG_VALUEs are emitted for vreg arguments.
X86InstrInfo now un-sets the debug instr number on SUB instructions that get mutated into CMP instructions. As the instruction no longer computes a subtraction, we can't use it for variable locations.
Differential Revision: https://reviews.llvm.org/D88898
show more ...
|
Revision tags: llvmorg-12.0.1-rc1 |
|
#
dee85d47 |
| 21-May-2021 |
Djordje Todorovic <djordje.todorovic@syrmia.com> |
[LiveDebugVariables] Stop trimming locations of non-inlined vars
The D35953, D62650 and D73691 introduced trimming of variables locations in LiveDebugVariables pass, since there are some cases where
[LiveDebugVariables] Stop trimming locations of non-inlined vars
The D35953, D62650 and D73691 introduced trimming of variables locations in LiveDebugVariables pass, since there are some cases where after the virtregrewrite we have exploded number of DBG_VALUEs created for some inlined variables. As it looks, all problematic cases were regarding inlined variables, so it seems reasonable to stop trimming the location ranges for non-inlined variables. It has very good impact on the llvm-locstats report.
Differential Revision: https://reviews.llvm.org/D102917
show more ...
|
#
8496fc2e |
| 26-May-2021 |
Jeremy Morse <jeremy.morse@sony.com> |
[DebugInstrRef][1/3] Track PHI values through register allocation
This patch introduces "DBG_PHI" instructions, a marker of where a PHI instruction used to be, before PHI elimination. Under the inst
[DebugInstrRef][1/3] Track PHI values through register allocation
This patch introduces "DBG_PHI" instructions, a marker of where a PHI instruction used to be, before PHI elimination. Under the instruction referencing model, we want to know where every value in the function is defined -- and a PHI, even if implicit, is such a place.
Just like instruction numbers, we can use this to identify a value to be used as a variable value, but we don't need to know what instruction defines that value, for example:
bb1: DBG_PHI $rax, 1 [... more insts ... ] bb2: DBG_INSTR_REF 1, 0, !1234, !DIExpression()
This specifies that on entry to bb1, whatever value is in $rax is known as value number one -- and the later DBG_INSTR_REF marks the position where variable !1234 should take on value number one.
PHI locations are stored in MachineFunction for the duration of the regalloc phase in the DebugPHIPositions map. The map is populated by PHIElimination, and then flushed back into the instruction stream by virtregrewriter. A small amount of maintenence is needed in LiveDebugVariables to account for registers being split, but only for individual positions, not for entire ranges of blocks.
Differential Revision: https://reviews.llvm.org/D86812
show more ...
|
#
7bc1dd11 |
| 07-May-2021 |
Stephen Tozer <Stephen.Tozer@Sony.com> |
Reapply "[DebugInfo] Drop DBG_VALUE_LISTs with an excessive number of debug operands"
Reapply b623df3c, which was reverted while reverting a different patch with a breaking change. There are no unde
Reapply "[DebugInfo] Drop DBG_VALUE_LISTs with an excessive number of debug operands"
Reapply b623df3c, which was reverted while reverting a different patch with a breaking change. There are no underlying issues with this patch, so no changes have been made to the original patch.
This reverts commit b11e4c990771541e440861f017afea7b4ba162f4.
show more ...
|
#
c9d4b417 |
| 07-May-2021 |
Simon Pilgrim <llvm-dev@redking.me.uk> |
[CodeGen] Ensure UserValue::getDebugLoc() and UserLabel::getDebugLoc() consistently return a const reference NFCI.
Avoids a lot of unnecessary tracking increments/decrements of the underlying Tracki
[CodeGen] Ensure UserValue::getDebugLoc() and UserLabel::getDebugLoc() consistently return a const reference NFCI.
Avoids a lot of unnecessary tracking increments/decrements of the underlying TrackingMDNodeRef.
show more ...
|
#
b11e4c99 |
| 30-Apr-2021 |
Nick Desaulniers <ndesaulniers@google.com> |
Revert "[DebugInfo] Drop DBG_VALUE_LISTs with an excessive number of debug operands"
This reverts commit b623df3c93983c4512aa54f2c706716bdf865a90, as per https://llvm.org/docs/DeveloperPolicy.html#p
Revert "[DebugInfo] Drop DBG_VALUE_LISTs with an excessive number of debug operands"
This reverts commit b623df3c93983c4512aa54f2c706716bdf865a90, as per https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy.
Breakages observed downstream reported in: https://reviews.llvm.org/D91722#2724321
Fixes exist in: https://reviews.llvm.org/D101523 https://reviews.llvm.org/D101540
but haven't landed yet going into the weekend.
show more ...
|
#
b622df3c |
| 28-Apr-2021 |
Stephen Tozer <Stephen.Tozer@Sony.com> |
[DebugInfo] Drop DBG_VALUE_LISTs with an excessive number of debug operands
This patch fixes a crash in LiveDebugVariables for inputs where a DBG_VALUE_LIST had 64 or more debug operands. This was t
[DebugInfo] Drop DBG_VALUE_LISTs with an excessive number of debug operands
This patch fixes a crash in LiveDebugVariables for inputs where a DBG_VALUE_LIST had 64 or more debug operands. This was triggering an assert, which was added under the assumption that only bad CodeGen would result in such a limit being hit, but relatively simple source files that result in these incredibly long debug values have been found, so this assert has been changed to a condition that drops the debug value if it is not met.
Differential Revision: https://reviews.llvm.org/D101373
show more ...
|
#
b98807df |
| 13-Apr-2021 |
Hongtao Yu <hoy@fb.com> |
[CSSPGO] Exclude pseudo probes from slot index
Pseudo probe are currently given a slot index like other regular instructions. This affects register pressure and lifetime weight computation because o
[CSSPGO] Exclude pseudo probes from slot index
Pseudo probe are currently given a slot index like other regular instructions. This affects register pressure and lifetime weight computation because of enlarged lifetime length with pseudo probe instructions. As a consequence, program could get different code generated w/ and w/o pseudo probes. I'm closing the gap by excluding pseudo probes from stack index and downstream register allocation related passes.
Reviewed By: wmi
Differential Revision: https://reviews.llvm.org/D100334
show more ...
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3 |
|
#
7d0cafba |
| 11-Sep-2020 |
gbtozers <stephen.tozer@sony.com> |
[DebugInfo] Process DBG_VALUE_LIST in LiveDebugVariables
This patch adds support for DBG_VALUE_LIST in the LiveDebugVariables pass. The changes are mostly in computeIntervals, extendDef, and addDefs
[DebugInfo] Process DBG_VALUE_LIST in LiveDebugVariables
This patch adds support for DBG_VALUE_LIST in the LiveDebugVariables pass. The changes are mostly in computeIntervals, extendDef, and addDefsFromCopies; when extending the def of a DBG_VALUE_LIST the live ranges of every used register must be considered, and when such a def is killed by more than one of its used registers being killed at the same time it is necessary to find valid copies of all of those registers to create a new def with.
The DebugVariableValue class has also been changed to reference multiple location numbers instead of just one. This has been accomplished by using a C-style array with a unique_ptr and an array length packed into 6 bits, to minimize the size of the class (which must be kept low to be used with IntervalMap). This may not be the most efficient solution possible, and should be looked at if performance issues arise.
Differential Revision: https://reviews.llvm.org/D83895
show more ...
|
#
d5adba10 |
| 14-Feb-2021 |
Kazu Hirata <kazu@google.com> |
[CodeGen] Use range-based for loops (NFC)
|
#
e15ae67a |
| 16-Jan-2021 |
Wei Mi <wmi@google.com> |
[LiveDebugVariables] Add cache for SkipPHIsLabelsAndDebug to prevent iterating the same PHI/LABEL/Debug instructions repeatedly.
We run into a compiling timeout problem when building a target after
[LiveDebugVariables] Add cache for SkipPHIsLabelsAndDebug to prevent iterating the same PHI/LABEL/Debug instructions repeatedly.
We run into a compiling timeout problem when building a target after its SampleFDO profile is updated. It is because some very large blocks with a bunch of PHIs at the beginning. LiveDebugVariables::emitDebugValues called during VirtRegRewriter phase searchs the insertion point for those large BBs repeatedly in SkipPHIsLabelsAndDebug, and each time SkipPHIsLabelsAndDebug needs to go through the same set of PHIs before it can find the first non PHI/Label/Debug instruction. This patch adds a cache to save the last position for the sequence which has been checked in the previous call of SkipPHIsLabelsAndDebug.
Differential Revision: https://reviews.llvm.org/D94981
show more ...
|
#
6464c4a1 |
| 25-Nov-2020 |
Robert Lougher <robert.lougher@sony.com> |
[LiveDebugVariables] Strip all debug instructions from nodebug functions
A crash/assertion failure in the greedy register allocator was tracked down to a debug instr being passed to LiveIntervals::g
[LiveDebugVariables] Strip all debug instructions from nodebug functions
A crash/assertion failure in the greedy register allocator was tracked down to a debug instr being passed to LiveIntervals::getInstructionIndex. Normally this should not occur as debug instructions are collected and removed by LiveDebugVariables before RA, and reinserted afterwards. However, when a function has no debug info, LiveDebugVariables simply strips any debug values that are present as they're not needed (this situation will occur when a function with debug info is inlined into a nodebug function). The problem is, it only removes DBG_VALUE instructions, leaving DBG_LABELs (the cause of the crash).
This patch updates the LiveDebugVariables nodebug path to remove all debug instructions. The test case verifies that DBG_VALUE/DBG_LABEL instructions are present, and that they are stripped.
When -experimental-debug-variable-locations is enabled, certain variable locations are represented by DBG_INSTR_REF instead of DBG_VALUE. The test case verifies that a DBG_INSTR_REF is emitted by the option, and that it is also stripped.
Differential Revision: https://reviews.llvm.org/D92127
show more ...
|
#
68ac02c0 |
| 22-Oct-2020 |
Jeremy Morse <jeremy.morse@sony.com> |
[DebugInstrRef] Pass DBG_INSTR_REFs through register allocation
Both FastRegAlloc and LiveDebugVariables/greedy need to cope with DBG_INSTR_REFs. None of them actually need to take any action, other
[DebugInstrRef] Pass DBG_INSTR_REFs through register allocation
Both FastRegAlloc and LiveDebugVariables/greedy need to cope with DBG_INSTR_REFs. None of them actually need to take any action, other than passing DBG_INSTR_REFs through: variable location information doesn't refer to any registers at this stage.
LiveDebugVariables stashes the instruction information in a tuple, then re-creates it later. This is only necessary as the register allocator doesn't expect to see any debug instructions while it's working. No equivalence classes or interval splitting is required at all!
No changes are needed for the fast register allocator, as it just ignores debug instructions. The test added checks that both of them preserve DBG_INSTR_REFs.
This also expands ScheduleDAGInstrs.cpp to treat DBG_INSTR_REFs the same as DBG_VALUEs when rescheduling instructions around. The current movement of DBG_VALUEs around is less than ideal, but it's not a regression to make DBG_INSTR_REFs subject to the same movement.
Differential Revision: https://reviews.llvm.org/D85757
show more ...
|
#
85ba2f16 |
| 17-Sep-2020 |
Simon Pilgrim <llvm-dev@redking.me.uk> |
LiveDebugVariables.cpp - remove unnecessary Compiler.h include. NFCI.
Already included in LiveDebugVariables.h
|
#
6e85c3d5 |
| 15-Sep-2020 |
Mircea Trofin <mtrofin@google.com> |
[NFC][Regalloc] accessors for 'reg' and 'weight'
Also renamed the fields to follow style guidelines.
Accessors help with readability - weight mutation, in particular, is easier to follow this way.
[NFC][Regalloc] accessors for 'reg' and 'weight'
Also renamed the fields to follow style guidelines.
Accessors help with readability - weight mutation, in particular, is easier to follow this way.
Differential Revision: https://reviews.llvm.org/D87725
show more ...
|
#
398ba372 |
| 04-Sep-2020 |
Fangrui Song <i@maskray.me> |
[LiveDebugVariables] Delete unneeded doInitialization
|