Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5 |
|
#
f6d431f2 |
| 24-Apr-2024 |
Xu Zhang <simonzgx@gmail.com> |
[CodeGen] Make the parameter TRI required in some functions. (#85968)
Fixes #82659
There are some functions, such as `findRegisterDefOperandIdx` and `findRegisterDefOperand`, that have too many
[CodeGen] Make the parameter TRI required in some functions. (#85968)
Fixes #82659
There are some functions, such as `findRegisterDefOperandIdx` and `findRegisterDefOperand`, that have too many default parameters. As a result, we have encountered some issues due to the lack of TRI parameters, as shown in issue #82411.
Following @RKSimon 's suggestion, this patch refactors 9 functions, including `{reads, kills, defines, modifies}Register`, `registerDefIsDead`, and `findRegister{UseOperandIdx, UseOperand, DefOperandIdx, DefOperand}`, adjusting the order of the TRI parameter and making it required. In addition, all the places that call these functions have also been updated correctly to ensure no additional impact.
After this, the caller of these functions should explicitly know whether to pass the `TargetRegisterInfo` or just a `nullptr`.
show more ...
|
Revision tags: llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init |
|
#
d871f40d |
| 13-Jan-2024 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Use DebugValueManager only when subprogram exists (#77978)
We previously scanned the whole BB for `DBG_VALUE` instruction even when
the program doesn't have debug info, i.e., the func
[WebAssembly] Use DebugValueManager only when subprogram exists (#77978)
We previously scanned the whole BB for `DBG_VALUE` instruction even when
the program doesn't have debug info, i.e., the function doesn't have a
subprogram associated with it, which can make compilation unnecessarily
slow. This disables `DebugValueManager` when a `DISubprogram` doesn't
exist for a function.
This only reduces unnecessary work in non-debug mode and does not change
output, so it's hard to add a test to test this behavior.
Test changes were necessary because their `DISubprogram`s were not
correctly linked with the functions, so with this PR the compiler
incorrectly assumed the functions didn't have a subprogram and the tests
started to fail.
Fixes https://github.com/emscripten-core/emscripten/issues/21048.
show more ...
|
Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init |
|
#
59723e40 |
| 18-Jun-2023 |
Kazu Hirata <kazu@google.com> |
[Target] Use llvm::is_contained (NFC)
|
Revision tags: llvmorg-16.0.6, llvmorg-16.0.5 |
|
#
ac73c48e |
| 20-May-2023 |
Elliot Goodrich <elliotgoodrich@gmail.com> |
[llvm] Reduce ComplexDeinterleavingPass.h includes
Remove the unnecessary `"llvm/IR/PatternMatch.h"` include directive from `ComplexDeinterleavingPass.h` and move it to the corresponding source file
[llvm] Reduce ComplexDeinterleavingPass.h includes
Remove the unnecessary `"llvm/IR/PatternMatch.h"` include directive from `ComplexDeinterleavingPass.h` and move it to the corresponding source file.
Add missing includes that were transitively included by this header to 3 other source files.
This reduces the total number of preprocessing tokens across the LLVM source files in `lib` from (roughly) 1,964,876,961 to 1,935,091,611 - a reduction of ~1.52%. This should result in a small improvement in compilation time.
show more ...
|
#
b7fb2a3f |
| 20-May-2023 |
Elliot Goodrich <elliotgoodrich@gmail.com> |
Revert "[llvm] Reduce ComplexDeinterleavingPass.h includes"
This reverts commit 058ca5c07106d38ad66e3ec4972a613a64e88151.
|
#
058ca5c0 |
| 20-May-2023 |
Elliot Goodrich <elliotgoodrich@gmail.com> |
[llvm] Reduce ComplexDeinterleavingPass.h includes
Remove the unnecessary `"llvm/IR/PatternMatch.h"` include directive from `ComplexDeinterleavingPass.h` and move it to the corresponding source file
[llvm] Reduce ComplexDeinterleavingPass.h includes
Remove the unnecessary `"llvm/IR/PatternMatch.h"` include directive from `ComplexDeinterleavingPass.h` and move it to the corresponding source file.
Add missing includes that were transitively included by this header to 2 other source files.
This reduces the total number of preprocessing tokens across the LLVM source files in `lib` from (roughly) 1,964,876,961 to 1,935,091,611 - a reduction of ~1.52%. This should result in a small improvement in compilation time.
Differential Revision: https://reviews.llvm.org/D150514
show more ...
|
Revision tags: llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2 |
|
#
97298353 |
| 16-Apr-2023 |
Kazu Hirata <kazu@google.com> |
[llvm] Apply fixes from readability-redundant-control-flow (NFC)
|
Revision tags: llvmorg-16.0.1 |
|
#
d20a1b87 |
| 27-Mar-2023 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Handle DebugLoc in DebugValueManager
According to https://llvm.org/docs/HowToUpdateDebugInfo.html#when-to-preserve-an-instruction-location, when moving (and in our case cloning) within
[WebAssembly] Handle DebugLoc in DebugValueManager
According to https://llvm.org/docs/HowToUpdateDebugInfo.html#when-to-preserve-an-instruction-location, when moving (and in our case cloning) within the same BB, the debug location is preserved. But when moving / cloning to a different BB, we preserve the debug location only if the destination BB contains the same location. Currently we preserve the debug loc unconditionally in all cases. This CL correctly handles the debug locs in DebugValueManager.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D148115
show more ...
|
#
b02db1dc |
| 29-Mar-2023 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Fix SmallVector warning
Fixes a build warning caused by D146744.
|
#
a4e32ae4 |
| 24-Mar-2023 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Do nothing when sinking to same place
In `DebugValueManager`, if a `Def` is requested to be sunk to the same place (i.e., `Insert` is right after `Def`, not counting `DBG_VALUE`s) curr
[WebAssembly] Do nothing when sinking to same place
In `DebugValueManager`, if a `Def` is requested to be sunk to the same place (i.e., `Insert` is right after `Def`, not counting `DBG_VALUE`s) currently we still do the sink. This can result in unnecessary creation of `DBG_VALUE $noreg`. See comments for details. This CL detects this case and do nothing and return, so we don't end up creating unnecessary undef `DBG_VALUE`s.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D146860
show more ...
|
Revision tags: llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7 |
|
#
5a55c950 |
| 30-Nov-2022 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Redesign DebugValueManager
The current `DebugValueManager`, which is mostly used in `RegStackify`, simply sinks `DBG_VALUE`s along when a def instruction sinks. (`RegStackify` only doe
[WebAssembly] Redesign DebugValueManager
The current `DebugValueManager`, which is mostly used in `RegStackify`, simply sinks `DBG_VALUE`s along when a def instruction sinks. (`RegStackify` only does sinks; it doesn't do hoists.)
But this simple strategy can result in incorrect combinations of variables' values which would have not been possible in the original program. In this case, LLVM's policy is to make the value unavailable, so they will be shown as 'optimized out', rather than showing inaccurate debug info. Especially, when an instruction sinks, its original `DBG_VALUE` should be set to undef. This is well illustrated in the third example in https://llvm.org/docs/SourceLevelDebugging.html#instruction-scheduling.
This CL rewrites `DebugValueManager` with this principle in mind. When sinking an instruction, it sinks its eligible `DBG_VALUE`s with it, but also leaves undef `DBG_VALUE`s in the original place to make those variables' values undefined.
Also, unlike the current version, we sink only an eligible subset of `DBG_VALUE`s with a def instruction. See comments in the code for details.
In case of cloning, because the original def is still there, we don't set its `DBG_VALUE`s to undef. But we clone only an eligible subset of `DBG_VALUE`s here as well.
One consequence of this change is that now we do sinking and cloning of the def instruction itself within the `DebugValueManager`'s `sink` and `clone` methods. This is necessary because the `DebugValueManager` needs to know the original def's location before sinking and cloning in order to scan other interfering `DBG_VALUE`s between the original def and the insertion point. If we want to separate these two, we need to call `DebugValueManager`'s `sink` and `clone` methods //before// sinking/cloning the def instruction, which I don't think is a good design alternative either, because the user of this class needs to pay extra attention when using it.
Because this change is fixing the existing inaccuracy of the current debug info, this reduces the variable info coverage in debug info, but not by a large margin. In Emscripten core benchmarks compiled with `-O1`, the coverage goes from 56.6% down to 55.2%, which I doubt will be a noticeable drop. The compilation time doesn't have any meaningful difference either with this change.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D146744
show more ...
|
#
999643f1 |
| 23-Mar-2023 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Tidy up DebugValueManager (NFC)
Misc. cleanups for `WebAssemblyDebugValueManager`. - Use `Register` for registers - Simpler for loop iteration - Rename a variable - Reorder methods -
[WebAssembly] Tidy up DebugValueManager (NFC)
Misc. cleanups for `WebAssemblyDebugValueManager`. - Use `Register` for registers - Simpler for loop iteration - Rename a variable - Reorder methods - Reduce `SmallVector` size for `DBG_VALUE`s to 1; one def usually have a single `DBG_VALUE` attached to it in most cases - Add a few more lines of comments
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D146743
show more ...
|
Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, 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, llvmorg-12.0.1-rc1 |
|
#
a64ebb86 |
| 23-May-2021 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Add NullifyDebugValueLists pass
`WebAssemblyDebugValueManager` does not currently handle `DBG_VALUE_LIST`, which is a recent addition to LLVM. We tried to nullify them within the const
[WebAssembly] Add NullifyDebugValueLists pass
`WebAssemblyDebugValueManager` does not currently handle `DBG_VALUE_LIST`, which is a recent addition to LLVM. We tried to nullify them within the constructor of `WebAssemblyDebugValueManager` in D102589, but it made the class error-prone to use because it deletes instructions within the constructor and thus invalidates existing iterators within the BB, so the user of the class should take special care not to use invalidated iterators. This actually caused a bug in ExplicitLocals pass.
Instead of trying to fix ExplicitLocals pass to make the iterator usage correct, which is possible but error-prone, this adds NullifyDebugValueLists pass that nullifies all `DBG_VALUE_LIST` instructions before we run WebAssembly specific passes in the backend. We can remove this pass after we implement handlers for `DBG_VALUE_LIST`s in `WebAssemblyDebugValueManager` and elsewhere.
Fixes https://github.com/emscripten-core/emscripten/issues/14255.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D102999
show more ...
|
#
6e1c1dac |
| 16-May-2021 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Nullify DBG_VALUE_LISTs in DebugValueManager
WebAssemblyDebugValueManager class currently does not handle DBG_VALUE_LIST instructions correctly for two reasons, which are explained in
[WebAssembly] Nullify DBG_VALUE_LISTs in DebugValueManager
WebAssemblyDebugValueManager class currently does not handle DBG_VALUE_LIST instructions correctly for two reasons, which are explained in https://bugs.llvm.org/show_bug.cgi?id=50361.
This effectively nullifies DBG_VALUE_LISTs in WebAssemblyDebugValueManager so that the info will appear as "optimized out" in debuggers but still be at least correct in the meantime.
Reviewed By: dschuff, jmorse
Differential Revision: https://reviews.llvm.org/D102589
show more ...
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4 |
|
#
1db137b1 |
| 10-Mar-2021 |
Stephen Tozer <Stephen.Tozer@Sony.com> |
[DebugInfo] Handle DBG_VALUES with multiple variable location operands in MIR
This patch adds handling for DBG_VALUE_LIST in the MIR-passes (after finalize-isel), excluding the debug liveness passes
[DebugInfo] Handle DBG_VALUES with multiple variable location operands in MIR
This patch adds handling for DBG_VALUE_LIST in the MIR-passes (after finalize-isel), excluding the debug liveness passes and DWARF emission. This most significantly affects MachineSink, which now needs to consider all used registers of a debug value when sinking, but for most passes this change is simply replacing getDebugOperand(0) with an iteration over all debug operands.
Differential Revision: https://reviews.llvm.org/D92578
show more ...
|
Revision tags: llvmorg-12.0.0-rc3 |
|
#
f6774130 |
| 04-Mar-2021 |
Stephen Tozer <Stephen.Tozer@Sony.com> |
Reapply "[DebugInfo] Add new instruction and DIExpression operator for variadic debug values"
Rewrites test to use correct architecture triple; fixes incorrect reference in SourceLevelDebugging doc
Reapply "[DebugInfo] Add new instruction and DIExpression operator for variadic debug values"
Rewrites test to use correct architecture triple; fixes incorrect reference in SourceLevelDebugging doc; simplifies `spillReg` behaviour so as to not be dependent on changes elsewhere in the patch stack.
This reverts commit d2000b45d033c06dc7973f59909a0ad12887ff51.
show more ...
|
#
d2000b45 |
| 04-Mar-2021 |
Stephen Tozer <Stephen.Tozer@Sony.com> |
Revert "[DebugInfo] Add new instruction and DIExpression operator for variadic debug values"
This reverts commit d07f106f4a48b6e941266525b6f7177834d7b74e.
|
Revision tags: 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 |
|
#
d07f106f |
| 11-Sep-2020 |
gbtozers <stephen.tozer@sony.com> |
[DebugInfo] Add new instruction and DIExpression operator for variadic debug values
This patch adds a new instruction that can represent variadic debug values, DBG_VALUE_VAR. This patch alone covers
[DebugInfo] Add new instruction and DIExpression operator for variadic debug values
This patch adds a new instruction that can represent variadic debug values, DBG_VALUE_VAR. This patch alone covers the addition of the instruction and a set of basic code changes in MachineInstr and a few adjacent areas, but does not correctly handle variadic debug values outside of these areas, nor does it generate them at any point.
The new instruction is similar to the existing DBG_VALUE instruction, with the following differences: the operands are in a different order, any number of values may be used in the instruction following the Variable and Expression operands (these are referred to in code as “debug operands”) and are indexed from 0 so that getDebugOperand(X) == getOperand(X+2), and the Expression in a DBG_VALUE_VAR must use the DW_OP_LLVM_arg operator to pass arguments into the expression.
The new DW_OP_LLVM_arg operator is only valid in expressions appearing in a DBG_VALUE_VAR; it takes a single argument and pushes the debug operand at the index given by the argument onto the Expression stack. For example the sub-expression `DW_OP_LLVM_arg, 0` has the meaning “Push the debug operand at index 0 onto the expression stack.”
Differential Revision: https://reviews.llvm.org/D82363
show more ...
|
#
e3c0b0fe |
| 08-Jan-2021 |
Wouter van Oortmerssen <aardappel@gmail.com> |
[WebAssembly] locals can now be indirect in DWARF
This for example to indicate that byval args are represented by a pointer to a struct. Followup to https://reviews.llvm.org/D94140
Differential Rev
[WebAssembly] locals can now be indirect in DWARF
This for example to indicate that byval args are represented by a pointer to a struct. Followup to https://reviews.llvm.org/D94140
Differential Revision: https://reviews.llvm.org/D94347
show more ...
|
#
5c38ae36 |
| 06-Jan-2021 |
Wouter van Oortmerssen <aardappel@gmail.com> |
[WebAssembly] Fixed byval args missing DWARF DW_AT_LOCATION
A struct in C passed by value did not get debug information. Such values are currently lowered to a Wasm local even in -O0 (not to an allo
[WebAssembly] Fixed byval args missing DWARF DW_AT_LOCATION
A struct in C passed by value did not get debug information. Such values are currently lowered to a Wasm local even in -O0 (not to an alloca like on other archs), which becomes a Target Index operand (TI_LOCAL). The DWARF writing code was not emitting locations in for TI's specifically if the location is a single range (not a list).
In addition, the ExplicitLocals pass which removes the ARGUMENT pseudo instructions did not update the associated DBG_VALUEs, and couldn't even find these values since the code assumed such instructions are adjacent, which is not the case here.
Also fixed asm printing of TIs needed by a test.
Differential Revision: https://reviews.llvm.org/D94140
show more ...
|
Revision tags: llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2 |
|
#
539381da |
| 22-Jun-2020 |
stozer <stephen.tozer@sony.com> |
[DebugInfo] Update MachineInstr to help support variadic DBG_VALUE instructions
Following on from this RFC[0] from a while back, this is the first patch towards implementing variadic debug values.
[DebugInfo] Update MachineInstr to help support variadic DBG_VALUE instructions
Following on from this RFC[0] from a while back, this is the first patch towards implementing variadic debug values.
This patch specifically adds a set of functions to MachineInstr for performing operations specific to debug values, and replacing uses of the more general functions where appropriate. The most prevalent of these is replacing getOperand(0) with getDebugOperand(0) for debug-value-specific code, as the operands corresponding to values will no longer be at index 0, but index 2 and upwards: getDebugOperand(x) == getOperand(x+2). Similar replacements have been added for the other operands, along with some helper functions to replace oft-repeated code and operate on a variable number of value operands.
[0] http://lists.llvm.org/pipermail/llvm-dev/2020-February/139376.html<Paste>
Differential Revision: https://reviews.llvm.org/D81852
show more ...
|
Revision tags: llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6 |
|
#
48139ebc |
| 20-Mar-2020 |
Wouter van Oortmerssen <aardappel@gmail.com> |
[WebAssembly] Add int32 DW_OP_WASM_location variant
This to allow us to add reloctable global indices as a symbol. Also adds R_WASM_GLOBAL_INDEX_I32 relocation type to support it.
See discussion in
[WebAssembly] Add int32 DW_OP_WASM_location variant
This to allow us to add reloctable global indices as a symbol. Also adds R_WASM_GLOBAL_INDEX_I32 relocation type to support it.
See discussion in https://github.com/WebAssembly/debugging/issues/12
show more ...
|
Revision tags: llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init |
|
#
adf7a0a5 |
| 20-Dec-2019 |
Yury Delendik <ydelendik@mozilla.com> |
[WebAssembly] Use TargetIndex operands in DbgValue to track WebAssembly operands locations
Extends DWARF expression language to express locals/globals locations. (via target-index operands atm) (pos
[WebAssembly] Use TargetIndex operands in DbgValue to track WebAssembly operands locations
Extends DWARF expression language to express locals/globals locations. (via target-index operands atm) (possible variants are: non-virtual registers or address spaces)
The WebAssemblyExplicitLocals can replace virtual registers to targertindex operand type at the time when WebAssembly backend introduces {get,set,tee}_local instead of corresponding virtual registers.
Reviewed By: aprantl, dschuff
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D52634
show more ...
|
Revision tags: llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
#
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <chandlerc@gmail.com> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
#
be24c020 |
| 15-Jan-2019 |
Yury Delendik <ydelendik@mozilla.com> |
[WebAssembly] Fix updating/moving DBG_VALUEs in RegStackify
Summary: As described in PR40209, there can be issues in DBG_VALUEs handling when multiple defs present in a BB. This patch adds logic for
[WebAssembly] Fix updating/moving DBG_VALUEs in RegStackify
Summary: As described in PR40209, there can be issues in DBG_VALUEs handling when multiple defs present in a BB. This patch adds logic for detection of related to def DBG_VALUEs and localizes register update and movement to found DBG_VALUEs.
Reviewers: aheejin
Subscribers: mgorny, dschuff, sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D56401
llvm-svn: 351216
show more ...
|