Revision tags: llvmorg-21-init |
|
#
196f7c2a |
| 24-Jan-2025 |
Artem Pianykh <artem.pyanykh@gmail.com> |
[Utils] Identity map module-level debug info on first use in CloneFunction* (#118627)
Summary: To avoid cloning module-level debug info (owned by the module rather than the function), CloneFunction
[Utils] Identity map module-level debug info on first use in CloneFunction* (#118627)
Summary: To avoid cloning module-level debug info (owned by the module rather than the function), CloneFunction implementation used to eagerly identity map such debug info into ValueMap's MD map. In larger modules with meaningful volume of debug info this gets very expensive.
By passing such debug info metadata via an IdentityMD set for the ValueMapper to map on first use, we get several benefits:
1. Mapping metadata is not cheap, particularly because of tracking. When cloning a Function we identity map lots of global module-level metadata to avoid cloning it, while only a fraction of it is actually used by the function. Mapping on first use is a lot faster for modules with meaningful amount of debug info.
2. Eagerly identity mapping metadata makes it harder to cache module-level data (e.g. a set of metadata nodes in a \a DICompileUnit). With this patch we can cache certain module-level metadata calculations to speed things up further.
Anecdata from compiling a sample cpp file with full debug info shows that this moderately speeds up CoroSplitPass which is one of the heavier users of cloning:
| | Baseline | IdentityMD set | |-----------------|----------|----------------| | CoroSplitPass | 306ms | 221ms | | CoroCloner | 101ms | 72ms | | Speed up | 1x | 1.4x |
Test Plan: ninja check-llvm-unit ninja check-llvm
show more ...
|
Revision tags: llvmorg-19.1.7 |
|
#
7e191038 |
| 13-Jan-2025 |
Pedro Lobo <pedro.lobo@tecnico.ulisboa.pt> |
[DebugInfo] Map VAM args to `poison` instead of `undef` [NFC] (#122756)
If an argument cannot be mapped in `Mapper::mapValue`, it can be mapped
to `poison` instead of `undef`.
|
Revision tags: llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1 |
|
#
e03f4271 |
| 19-Sep-2024 |
Jay Foad <jay.foad@amd.com> |
[LLVM] Use {} instead of std::nullopt to initialize empty ArrayRef (#109133)
It is almost always simpler to use {} instead of std::nullopt to
initialize an empty ArrayRef. This patch changes all oc
[LLVM] Use {} instead of std::nullopt to initialize empty ArrayRef (#109133)
It is almost always simpler to use {} instead of std::nullopt to
initialize an empty ArrayRef. This patch changes all occurrences I could
find in LLVM itself. In future the ArrayRef(std::nullopt_t) constructor
could be deprecated or removed.
show more ...
|
Revision tags: llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2 |
|
#
e525f916 |
| 04-Aug-2024 |
Kazu Hirata <kazu@google.com> |
[llvm] Use llvm::is_contained (NFC) (#101855)
|
#
34d48279 |
| 29-Jul-2024 |
Kazu Hirata <kazu@google.com> |
[llvm] Initialize SmallVector with ranges (NFC) (#100948)
|
Revision tags: llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6 |
|
#
a6171900 |
| 08-May-2024 |
Harald van Dijk <harald.vandijk@codeplay.com> |
[RemoveDIs] Change remapDbgVariableRecord to remapDbgRecord (#91456)
We need to remap any DbgRecord, not just DbgVariableRecords.
This is the followup to #91447.
Co-authored-by: PietroGhg <pie
[RemoveDIs] Change remapDbgVariableRecord to remapDbgRecord (#91456)
We need to remap any DbgRecord, not just DbgVariableRecords.
This is the followup to #91447.
Co-authored-by: PietroGhg <pietro.ghiglio@codeplay.com>
show more ...
|
#
927913fa |
| 08-May-2024 |
Harald van Dijk <harald.vandijk@codeplay.com> |
[RemoveDIs] Fix remapping of DbgLabelRecords. (#91447)
We already remapped DILocations for DbgVariableRecords, but
DbgLabelRecords have debug locations too that need to be mapped the same
way.
|
Revision tags: llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3 |
|
#
bdc77d1e |
| 20-Mar-2024 |
Stephen Tozer <stephen.tozer@sony.com> |
[RemoveDIs][NFC] Rename DPLabel->DbgLabelRecord (#85918)
This patch renames DPLabel to DbgLabelRecord, in accordance with the
ongoing DbgRecord rename. This rename was fairly trivial, since DPLabel
[RemoveDIs][NFC] Rename DPLabel->DbgLabelRecord (#85918)
This patch renames DPLabel to DbgLabelRecord, in accordance with the
ongoing DbgRecord rename. This rename was fairly trivial, since DPLabel
isn't as widely used as DPValue and has no real conflicts in either its
full or abbreviated name. As usual, the entire replacement was done
automatically, with `s/DPLabel/DbgLabelRecord/` and `s/DPL/DLR/`.
show more ...
|
Revision tags: llvmorg-18.1.2 |
|
#
ffd08c77 |
| 19-Mar-2024 |
Stephen Tozer <stephen.tozer@sony.com> |
[RemoveDIs][NFC] Rename DPValue -> DbgVariableRecord (#85216)
This is the major rename patch that prior patches have built towards.
The DPValue class is being renamed to DbgVariableRecord, which re
[RemoveDIs][NFC] Rename DPValue -> DbgVariableRecord (#85216)
This is the major rename patch that prior patches have built towards.
The DPValue class is being renamed to DbgVariableRecord, which reflects
the updated terminology for the "final" implementation of the RemoveDI
feature. This is a pure string substitution + clang-format patch. The
only manual component of this patch was determining where to perform
these string substitutions: `DPValue` and `DPV` are almost exclusively
used for DbgRecords, *except* for:
- llvm/lib/target, where 'DP' is used to mean double-precision, and so
appears as part of .td files and in variable names. NB: There is a
single existing use of `DPValue` here that refers to debug info, which
I've manually updated.
- llvm/tools/gold, where 'LDPV' is used as a prefix for symbol
visibility enums.
Outside of these places, I've applied several basic string
substitutions, with the intent that they only affect DbgRecord-related
identifiers; I've checked them as I went through to verify this, with
reasonable confidence that there are no unintended changes that slipped
through the cracks. The substitutions applied are all case-sensitive,
and are applied in the order shown:
```
DPValue -> DbgVariableRecord
DPVal -> DbgVarRec
DPV -> DVR
```
Following the previous rename patches, it should be the case that there
are no instances of any of these strings that are meant to refer to the
general case of DbgRecords, or anything other than the DPValue class.
The idea behind this patch is therefore that pure string substitution is
correct in all cases as long as these assumptions hold.
show more ...
|
#
2e865353 |
| 14-Mar-2024 |
Stephen Tozer <stephen.tozer@sony.com> |
[RemoveDIs][NFC] Move DPValue::filter -> filterDbgVars (#85208)
This patch changes DPValue::filter to be a non-member method
filterDbgVars. There are two reasons for this: firstly, the name of
DPV
[RemoveDIs][NFC] Move DPValue::filter -> filterDbgVars (#85208)
This patch changes DPValue::filter to be a non-member method
filterDbgVars. There are two reasons for this: firstly, the name of
DPValue is about to change to DbgVariableRecord, which will result in
every `for` loop that uses DPValue::filter to require a line break. This
is a small thing, but it makes the rename patch more difficult to
review, and is just generally more awkward for what is a fairly common
loop. Secondly, the intent is to later break up the DPValue class into
subclasses, at which point it would be better to have a non-member
function that allows template arguments for the cases we want to filter
with greater specificity.
show more ...
|
#
360da838 |
| 13-Mar-2024 |
Stephen Tozer <stephen.tozer@sony.com> |
[RemoveDI][NFC] Rename DPValue->DbgRecord in comments and varnames (#84939)
This patch continues the ongoing rename work, replacing DPValue with
DbgRecord in comments and the names of variables, bo
[RemoveDI][NFC] Rename DPValue->DbgRecord in comments and varnames (#84939)
This patch continues the ongoing rename work, replacing DPValue with
DbgRecord in comments and the names of variables, both members and
fn-local. This is the most labour-intensive part of the rename, as it is
where the most decisions have to be made about whether a given comment
or variable is referring to DPValues (equivalent to debug variable
intrinsics) or DbgRecords (a catch-all for all debug intrinsics); these
decisions are not individually difficult, but comprise a fairly large
amount of text to review.
This patch still largely performs basic string substitutions followed by
clang-format; there are almost* no places where, for example, a comment
has been expanded or modified to reflect the semantic difference between
DPValues and DbgRecords. I don't believe such a change is generally
necessary in LLVM, but it may be useful in the docs, and so I'll be
submitting docs changes as a separate patch.
*In a few places, `dbg.values` was replaced with `debug intrinsics`.
show more ...
|
#
15f3f446 |
| 12-Mar-2024 |
Stephen Tozer <stephen.tozer@sony.com> |
[RemoveDIs][NFC] Rename common interface functions for DPValues->DbgRecords (#84793)
As part of the effort to rename the DbgRecord classes, this patch
renames the widely-used functions that operate
[RemoveDIs][NFC] Rename common interface functions for DPValues->DbgRecords (#84793)
As part of the effort to rename the DbgRecord classes, this patch
renames the widely-used functions that operate on DbgRecords but refer
to DbgValues or DPValues in their names to refer to DbgRecords instead;
all such functions are defined in one of `BasicBlock.h`,
`Instruction.h`, and `DebugProgramInstruction.h`.
This patch explicitly does not change the names of any comments or
variables, except for where they use the exact name of one of the
renamed functions. The reason for this is reviewability; this patch can
be trivially examined to determine that the only changes are direct
string substitutions and any results from clang-format responding to the
changed line lengths. Future patches will cover renaming variables and
comments, and then renaming the classes themselves.
show more ...
|
Revision tags: llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4 |
|
#
8a164220 |
| 23-Feb-2024 |
Orlando Cazalet-Hyams <orlando.hyams@sony.com> |
[RemoveDIs] Add DPLabels support [3a/3] (#82633)
Patch 2 of 3 to add llvm.dbg.label support to the RemoveDIs project. The
patch stack adds the DPLabel class, which is the RemoveDIs llvm.dbg.label
[RemoveDIs] Add DPLabels support [3a/3] (#82633)
Patch 2 of 3 to add llvm.dbg.label support to the RemoveDIs project. The
patch stack adds the DPLabel class, which is the RemoveDIs llvm.dbg.label
equivalent.
1. Add DbgRecord base class for DPValue and the not-yet-added
DPLabel class.
2. Add the DPLabel class.
-> 3. Add support to passes.
The next patch, #82639, will enable conversion between dbg.labels and DPLabels.
AssignemntTrackingAnalysis support could have gone two ways:
1. Have the analysis store a DPLabel representation in its results -
SelectionDAGBuilder reads the analysis results and ignores all DbgRecord
kinds.
2. Ignore DPLabels in the analysis - SelectionDAGBuilder reads the analysis
results but still needs to iterate over DPLabels from the IR.
I went with option 2 because it's less work and is no less correct than 1. It's
worth noting that causes labels to sink to the bottom of packs of debug records.
e.g., [value, label, value] becomes [value, value, label]. This shouldn't be a
problem because labels and variable locations don't have an ordering requirement.
The ordering between variable locations is maintained and the label movement is
deterministic
show more ...
|
Revision tags: llvmorg-18.1.0-rc3 |
|
#
ababa964 |
| 20-Feb-2024 |
Orlando Cazalet-Hyams <orlando.hyams@sony.com> |
[RemoveDIs][NFC] Introduce DbgRecord base class [1/3] (#78252)
Patch 1 of 3 to add llvm.dbg.label support to the RemoveDIs project. The
patch stack adds a new base class
-> 1. Add DbgRecord
[RemoveDIs][NFC] Introduce DbgRecord base class [1/3] (#78252)
Patch 1 of 3 to add llvm.dbg.label support to the RemoveDIs project. The
patch stack adds a new base class
-> 1. Add DbgRecord base class for DPValue and the not-yet-added
DPLabel class.
2. Add the DPLabel class.
3. Enable dbg.label conversion and add support to passes.
Patches 1 and 2 are NFC.
In the near future we also will rename DPValue to DbgVariableRecord and
DPLabel to DbgLabelRecord, at which point we'll overhaul the function
names too. The name DPLabel keeps things consistent for now.
show more ...
|
#
97088b2a |
| 13-Feb-2024 |
Orlando Cazalet-Hyams <orlando.hyams@sony.com> |
[RemoveDIs][ValueMapper] Remap DIAssignIDs in DPValues (#81595)
Fix crash raised in comments for 5c9f7682b090124d9a8b69f92d3f7c269dca25fc
|
Revision tags: llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1 |
|
#
a19629da |
| 25-Jan-2024 |
Jeremy Morse <jeremy.morse@sony.com> |
Reapply 215b8f1e252, reverted in c3f7fb1421e
Turns out I was using DbgMarker::getDbgValueRange rather than the helper utility in Instruction::getDbgValueRange, which checks for null-ness. Original c
Reapply 215b8f1e252, reverted in c3f7fb1421e
Turns out I was using DbgMarker::getDbgValueRange rather than the helper utility in Instruction::getDbgValueRange, which checks for null-ness. Original commit message follows.
[DebugInfo][RemoveDIs] Convert debug-info modes when loading bitcode (#78967)
As part of eliminating debug-intrinsics in LLVM, we'll shortly be pushing the conversion from "old" dbg.value mode to "new" DPValue mode out from when the pass manager runs, to when modules are loaded. This patch adds that conversion process and some (temporary) options to llvm-lto{,2} to help test it.
Specifically: now whenever we load a bitcode module, consider a flag of whether to "upgrade" it into the new debug-info mode, and if we're lazily materializing functions then do that lazily too. Doing this exposes an error in the IRLinker/materializer handling of DPValues, where we need to transfer the debug-info format flag correctly, and in ValueMapper we need to remap the Values that DPValues point at.
I've added some test coverage in the modified tests; these will be exercised by our llvm-new-debug-iterators buildbot.
This upgrading of debug-info won't be happening for the llvm18 release, instead we'll turn it on after the branch date, thenbe push the boundary of where "new" debug-info starts and ends down into the existing debug-info upgrade path over the course of the next release.
show more ...
|
#
c3f7fb14 |
| 25-Jan-2024 |
Jeremy Morse <jeremy.morse@sony.com> |
Revert "[DebugInfo][RemoveDIs] Convert debug-info modes when loading bitcode (#78967)"
This reverts commit 215b8f1e252b4f30cf1b734faa370c0ac4b88659.
Numerous builders exploded from this X_X, for ex
Revert "[DebugInfo][RemoveDIs] Convert debug-info modes when loading bitcode (#78967)"
This reverts commit 215b8f1e252b4f30cf1b734faa370c0ac4b88659.
Numerous builders exploded from this X_X, for example
https://lab.llvm.org/buildbot/#/builders/46/builds/62657
show more ...
|
#
215b8f1e |
| 25-Jan-2024 |
Jeremy Morse <jeremy.morse@sony.com> |
[DebugInfo][RemoveDIs] Convert debug-info modes when loading bitcode (#78967)
As part of eliminating debug-intrinsics in LLVM, we'll shortly be
pushing the conversion from "old" dbg.value mode to "
[DebugInfo][RemoveDIs] Convert debug-info modes when loading bitcode (#78967)
As part of eliminating debug-intrinsics in LLVM, we'll shortly be
pushing the conversion from "old" dbg.value mode to "new" DPValue mode
out from when the pass manager runs, to when modules are loaded. This
patch adds that conversion process and some (temporary) options to
llvm-lto{,2} to help test it.
Specifically: now whenever we load a bitcode module, consider a flag of
whether to "upgrade" it into the new debug-info mode, and if we're
lazily materializing functions then do that lazily too. Doing this
exposes an error in the IRLinker/materializer handling of DPValues,
where we need to transfer the debug-info format flag correctly, and in
ValueMapper we need to remap the Values that DPValues point at.
I've added some test coverage in the modified tests; these will be
exercised by our llvm-new-debug-iterators buildbot.
This upgrading of debug-info won't be happening for the llvm18 release,
instead we'll turn it on after the branch date, thenbe push the boundary
of where "new" debug-info starts and ends down into the existing
debug-info upgrade path over the course of the next release.
show more ...
|
Revision tags: llvmorg-19-init |
|
#
632f44e5 |
| 23-Jan-2024 |
Stephen Tozer <stephen.tozer@sony.com> |
[RemoveDIs][DebugInfo] Handle DPVAssign in most transforms (#78986)
This patch trivially updates various opt passes to handle DPVAssigns. In
all cases, this means some combination of generifying ex
[RemoveDIs][DebugInfo] Handle DPVAssign in most transforms (#78986)
This patch trivially updates various opt passes to handle DPVAssigns. In
all cases, this means some combination of generifying existing code to
handle DPValues and DbgAssignIntrinsics, iterating over DPValues where
previously we did not, or duplicating code for DbgAssignIntrinsics to
the equivalent DPValue function (in inlining and salvageDebugInfo).
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, llvmorg-16.0.6 |
|
#
59fab226 |
| 07-Jun-2023 |
Jeremy Morse <jeremy.morse@sony.com> |
[DebugInfo][RemoveDIs] Support cloning and remapping DPValues (#72546)
This patch adds support for CloneBasicBlock duplicating the DPValues attached to instructions, and adds facilities to remap the
[DebugInfo][RemoveDIs] Support cloning and remapping DPValues (#72546)
This patch adds support for CloneBasicBlock duplicating the DPValues attached to instructions, and adds facilities to remap them into their new context. The plumbing to achieve this is fairly straightforwards and mechanical.
I've also added illustrative uses to LoopUnrollRuntime, SimpleLoopUnswitch and SimplifyCFG. The former only updates for the epilogue right now so I've added CHECK lines just for the end of an unrolled loop (further updates coming later). SimpleLoopUnswitch had no debug-info tests so I've added a new one. The two modified parts of SimplifyCFG are covered by the two modified SimplifyCFG tests.
These are scenarios where we have to do extra cloning for copying of DPValues because they're no longer instructions, and remap them too.
show more ...
|
#
243f0566 |
| 28-Jun-2023 |
Youngsuk Kim <youngsuk.kim@hpe.com> |
[llvm] Replace uses of Type::getPointerTo (NFC)
Partial progress towards removing in-tree uses of `Type::getPointerTo`, before we can deprecate the API.
If the API is used solely to support an unne
[llvm] Replace uses of Type::getPointerTo (NFC)
Partial progress towards removing in-tree uses of `Type::getPointerTo`, before we can deprecate the API.
If the API is used solely to support an unnecessary bitcast, get rid of the bitcast as well.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D153933
show more ...
|
Revision tags: llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3 |
|
#
c2f29f24 |
| 25-Apr-2023 |
Bing1 Yu <bing1.yu@intel.com> |
[ValueMapper] allow mapping ConstantTargetNone to its layout type
zeroinitializer is allowed for spirv TargetExtType. This PR allows ValueMapper to map TargetExtType ConstantTargetNone to '0' consta
[ValueMapper] allow mapping ConstantTargetNone to its layout type
zeroinitializer is allowed for spirv TargetExtType. This PR allows ValueMapper to map TargetExtType ConstantTargetNone to '0' constant of its layout type.
Reviewed By: jcranmer-intel
Differential Revision: https://reviews.llvm.org/D148774
show more ...
|
Revision tags: llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0 |
|
#
2aaaed35 |
| 13-Mar-2023 |
Carl Ritson <carl.ritson@amd.com> |
[IRLinker] Fix mapping of declaration metadata
Ensure metadata for declarations copied during materialization is properly mapped if declarations do not become definitions.
Reviewed By: tejohnson
D
[IRLinker] Fix mapping of declaration metadata
Ensure metadata for declarations copied during materialization is properly mapped if declarations do not become definitions.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D145318
show more ...
|
Revision tags: llvmorg-16.0.0-rc4 |
|
#
e510d0bd |
| 08-Mar-2023 |
Carl Ritson <carl.ritson@amd.com> |
Revert "[IRLinker] Fix mapping of declaration metadata"
This reverts commit be0ef4b95d947a324aaf58373691723a0307822b. Investigating use after free issue.
|
#
be0ef4b9 |
| 08-Mar-2023 |
Carl Ritson <carl.ritson@amd.com> |
[IRLinker] Fix mapping of declaration metadata
Ensure metadata for declarations copied during materialization is properly mapped if declarations do not become definitions.
Reviewed By: tejohnson
D
[IRLinker] Fix mapping of declaration metadata
Ensure metadata for declarations copied during materialization is properly mapped if declarations do not become definitions.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D145318
show more ...
|