History log of /llvm-project/llvm/lib/Transforms/Utils/ValueMapper.cpp (Results 1 – 25 of 282)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...


12345678910>>...12