[NFC][DebugInfo] Use iterator moveBefore at many call-sites (#123583)

As part of the "RemoveDIs" project, BasicBlock::iterator now carries a
debug-info bit that's needed when getFirstNonPHI and sim

[NFC][DebugInfo] Use iterator moveBefore at many call-sites (#123583)

As part of the "RemoveDIs" project, BasicBlock::iterator now carries a
debug-info bit that's needed when getFirstNonPHI and similar feed into
instruction insertion positions. Call-sites where that's necessary were
updated a year ago; but to ensure some type safety however, we'd like to
have all calls to moveBefore use iterators.

This patch adds a (guaranteed dereferenceable) iterator-taking
moveBefore, and changes a bunch of call-sites where it's obviously safe
to change to use it by just calling getIterator() on an instruction
pointer. A follow-up patch will contain less-obviously-safe changes.

We'll eventually deprecate and remove the instruction-pointer
insertBefore, but not before adding concise documentation of what
considerations are needed (very few).

show more ...

[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 ...

[NFC][Utils] Eliminate DISubprogram set from BuildDebugInfoMDMap (#118625)


Summary:
Previously, we'd add all SPs distinct from the cloned one into a set.
Then when cloning a local scope we'd check

[NFC][Utils] Eliminate DISubprogram set from BuildDebugInfoMDMap (#118625)


Summary:
Previously, we'd add all SPs distinct from the cloned one into a set.
Then when cloning a local scope we'd check if it's from one of those
'distinct' SPs by checking if it's in the set. We don't need to do that.
We can just check against the cloned SP directly and drop the set.

Test Plan:
ninja check-llvm-unit check-llvm

show more ...

[NFC][Utils] Extract CloneFunctionBodyInto from CloneFunctionInto (#118624)


Summary:
This and previously extracted `CloneFunction*Into` functions will be used in later diffs.

Test Plan:
ninja chec

[NFC][Utils] Extract CloneFunctionBodyInto from CloneFunctionInto (#118624)


Summary:
This and previously extracted `CloneFunction*Into` functions will be used in later diffs.

Test Plan:
ninja check-llvm-unit check-llvm

show more ...

[NFC][Utils] Extract CloneFunctionMetadataInto from CloneFunctionInto (#118623)


Summary:
The new API expects the caller to populate the VMap. We need it this way
for a subsequent change around coro

[NFC][Utils] Extract CloneFunctionMetadataInto from CloneFunctionInto (#118623)


Summary:
The new API expects the caller to populate the VMap. We need it this way
for a subsequent change around coroutine cloning.

Test Plan:
ninja check-llvm-unit check-llvm

show more ...

[NFC][Utils] Extract BuildDebugInfoMDMap from CloneFunctionInto (#118622)


Summary:
Extract the logic to build up a metadata map to use in metadata cloning
into a separate function.

Test Plan:
ninj

[NFC][Utils] Extract BuildDebugInfoMDMap from CloneFunctionInto (#118622)


Summary:
Extract the logic to build up a metadata map to use in metadata cloning
into a separate function.

Test Plan:
ninja check-llvm-unit check-llvm

show more ...

[NFC][Utils] Clone basic blocks after we're done with metadata in CloneFunctionInto (#118621)


Summary:
Moving the cloning of BBs after the metadata makes the flow of the
function a bit more straigh

[NFC][Utils] Clone basic blocks after we're done with metadata in CloneFunctionInto (#118621)


Summary:
Moving the cloning of BBs after the metadata makes the flow of the
function a bit more straightforward and makes it easier to extract more
into helper functions.

Test Plan:
ninja check-llvm-unit check-llvm

show more ...

[NFC][Utils] Remove DebugInfoFinder parameter from CloneBasicBlock (#118620)


Summary:
There was a single usage of CloneBasicBlock with non-default
DebugInfoFinder inside CloneFunctionInto which has

[NFC][Utils] Remove DebugInfoFinder parameter from CloneBasicBlock (#118620)


Summary:
There was a single usage of CloneBasicBlock with non-default
DebugInfoFinder inside CloneFunctionInto which has been refactored in
more focused.

Test Plan:
ninja check-llvm-unit check-llvm

show more ...

[Utils] Extract CollectDebugInfoForCloning from CloneFunctionInto (#114537)

Summary:
Consolidate the logic in a single function. We do an extra pass over
Instructions but this is necessary to unta

[Utils] Extract CollectDebugInfoForCloning from CloneFunctionInto (#114537)

Summary:
Consolidate the logic in a single function. We do an extra pass over
Instructions but this is necessary to untangle things and extract
metadata cloning in a future diff.

Test Plan:
```
$ ninja check-llvm-unit check-llvm
[211/213] Running the LLVM regression tests

Testing Time: 106.06s

Total Discovered Tests: 62601
Skipped : 17 (0.03%)
Unsupported : 2518 (4.02%)
Passed : 59911 (95.70%)
Expectedly Failed: 155 (0.25%)
[212/213] Running lit suite

Testing Time: 12.47s

Total Discovered Tests: 8474
Skipped: 17 (0.20%)
Passed : 8457 (99.80%)
```

Extracted from #109032 (commit 3) (there are more refactors and cleanups
in subsequent commits)

show more ...

[Utils] Remove unused includes (NFC) (#114748)

Identified with misc-include-cleaner.

[NFC][Utils] Extract CloneFunctionAttributesInto from CloneFunctionInto (#112976)

This patch is a part of step-by-step refactoring of CloneFunctionInto.
The goal is to extract reusable pieces out o

[NFC][Utils] Extract CloneFunctionAttributesInto from CloneFunctionInto (#112976)

This patch is a part of step-by-step refactoring of CloneFunctionInto.
The goal is to extract reusable pieces out of it that will be later used
to optimize function cloning e.g. in coroutine processing.

Extracted from #109032 (commit 2)

show more ...

[SimplifyLibCall][Attribute] Fix bug where we may keep `range` attr with incompatible type (#112649)

In a variety of places we change the bitwidth of a parameter but don't
update the attributes.

[SimplifyLibCall][Attribute] Fix bug where we may keep `range` attr with incompatible type (#112649)

In a variety of places we change the bitwidth of a parameter but don't
update the attributes.

The issue in this case is from the `range` attribute when inlining
`__memset_chk`. `optimizeMemSetChk` will replace an `i32` with an
`i8`, and if the `i32` had a `range` attr assosiated it will cause an
error.

Fixes #112633

show more ...

[NFC] Rename `Intrinsic::getDeclaration` to `getOrInsertDeclaration` (#111752)

Rename the function to reflect its correct behavior and to be consistent
with `Module::getOrInsertFunction`. This is a

[NFC] Rename `Intrinsic::getDeclaration` to `getOrInsertDeclaration` (#111752)

Rename the function to reflect its correct behavior and to be consistent
with `Module::getOrInsertFunction`. This is also in preparation of
adding a new `Intrinsic::getDeclaration` that will have behavior similar
to `Module::getFunction` (i.e, just lookup, no creation).

show more ...

[MemProf] Strip callsite metadata when inlining an unprofiled callsite (#110998)

We weren't flagging inlined callee functions with callsite but not
memprof metadata correctly, leading to the callsi

[MemProf] Strip callsite metadata when inlining an unprofiled callsite (#110998)

We weren't flagging inlined callee functions with callsite but not
memprof metadata correctly, leading to the callsite metadata not being
stripped when that function was inlined into a callsite that didn't
itself have callsite metadata.

In practice, this meant that we went into the LTO link with many more
calls than necessary having callsite metadata / summary records, which
in turn made the graph larger than necessary.

Fixing this oversight resulted in huge reductions in the thin link of a
large target:
99% fewer duplicated context ids (recall we have to duplicate when
callsites containing the same stack ids are in different functions)
71% fewer graph edges
17% fewer graph nodes
13% fewer functions cloned
44% smaller peak memory
47% smaller time

show more ...

[ExtendLifetimes] Implement llvm.fake.use to extend variable lifetimes (#86149)

This patch is part of a set of patches that add an `-fextend-lifetimes`
flag to clang, which extends the lifetimes of

[ExtendLifetimes] Implement llvm.fake.use to extend variable lifetimes (#86149)

This patch is part of a set of patches that add an `-fextend-lifetimes`
flag to clang, which extends the lifetimes of local variables and
parameters for improved debuggability. In addition to that flag, the
patch series adds a pragma to selectively disable `-fextend-lifetimes`,
and an `-fextend-this-ptr` flag which functions as `-fextend-lifetimes`
for this pointers only. All changes and tests in these patches were
written by Wolfgang Pieb (@wolfy1961), while Stephen Tozer (@SLTozer)
has handled review and merging. The extend lifetimes flag is intended to
eventually be set on by `-Og`, as discussed in the RFC
here:

https://discourse.llvm.org/t/rfc-redefine-og-o1-and-add-a-new-level-of-og/72850

This patch implements a new intrinsic instruction in LLVM,
`llvm.fake.use` in IR and `FAKE_USE` in MIR, that takes a single operand
and has no effect other than "using" its operand, to ensure that its
operand remains live until after the fake use. This patch does not emit
fake uses anywhere; the next patch in this sequence causes them to be
emitted from the clang frontend, such that for each variable (or this) a
fake.use operand is inserted at the end of that variable's scope, using
that variable's value. This patch covers everything post-frontend, which
is largely just the basic plumbing for a new intrinsic/instruction,
along with a few steps to preserve the fake uses through optimizations
(such as moving them ahead of a tail call or translating them through
SROA).

Co-authored-by: Stephen Tozer <stephen.tozer@sony.com>

show more ...

[IR] Add getDataLayout() helpers to Function and GlobalValue (#96919)

Similar to https://github.com/llvm/llvm-project/pull/96902, this adds
`getDataLayout()` helpers to Function and GlobalValue, re

[IR] Add getDataLayout() helpers to Function and GlobalValue (#96919)

Similar to https://github.com/llvm/llvm-project/pull/96902, this adds
`getDataLayout()` helpers to Function and GlobalValue, replacing the
current `getParent()->getDataLayout()` pattern.

show more ...

[IR] Add getDataLayout() helpers to BasicBlock and Instruction (#96902)

This is a helper to avoid writing `getModule()->getDataLayout()`. I
regularly try to use this method only to remember it does

[IR] Add getDataLayout() helpers to BasicBlock and Instruction (#96902)

This is a helper to avoid writing `getModule()->getDataLayout()`. I
regularly try to use this method only to remember it doesn't exist...

`getModule()->getDataLayout()` is also a common (the most common?)
reason why code has to include the Module.h header.

show more ...

[CloneFunction] Remove check that is no longer necessary (#92577)

We do not need to concern ourselves with CGSCC since all remaining CG
related updates went away in fa6ea7a419f37befbed04368bcb8af4c

[CloneFunction] Remove check that is no longer necessary (#92577)

We do not need to concern ourselves with CGSCC since all remaining CG
related updates went away in fa6ea7a419f37befbed04368bcb8af4c718facbb as
pointed out by @nikic in
https://github.com/llvm/llvm-project/pull/87963#issuecomment-2113937182.

show more ...

[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 ...

[NFC][LLVM] Refactor rounding mode detection of constrained fp intrinsic IDs (#90854)

I've refactored the code to genericise the implementation to better
allow for target specific constrained fp in

[NFC][LLVM] Refactor rounding mode detection of constrained fp intrinsic IDs (#90854)

I've refactored the code to genericise the implementation to better
allow for target specific constrained fp intrinsics.

show more ...

[Inline][Cloning] Drop incompatible attributes from `NewFunc`

Performing `instSimplify` while cloning is unsafe due to incomplete
remapping (as reported in #87534). Ideally, `instSimplify` ought to

[Inline][Cloning] Drop incompatible attributes from `NewFunc`

Performing `instSimplify` while cloning is unsafe due to incomplete
remapping (as reported in #87534). Ideally, `instSimplify` ought to
reason on the updated newly-cloned function, after returns have been
rewritten and callee entry basic block / call-site have been fixed up.
This is in contrast to `CloneAndPruneIntoFromInst` behaviour, which
is inherently expected to clone basic blocks, with pruning on top of
– if any –, and not actually fixing up returns / CFG, which should be
up to the Inliner. We may solve this by letting `instSimplify` work on
the newly-cloned function, while maintaining old function attributes,
so as to avoid inconsistencies between the yet-to-be-solved return
type, and new function ret type attributes.

show more ...

Reapply "[Inline][Cloning] Defer simplification after phi-nodes resolution"

Original commit: a61f9fe31750cee65c726fb51f1b14e31e177258

Multiple 2-stage buildbots were reporting failures. These issue

Reapply "[Inline][Cloning] Defer simplification after phi-nodes resolution"

Original commit: a61f9fe31750cee65c726fb51f1b14e31e177258

Multiple 2-stage buildbots were reporting failures. These issues have been
addressed separately.

Fixes: https://github.com/llvm/llvm-project/issues/87534.

show more ...

[Transforms] Debug values are not remapped when cloning. (#87747)

When cloning instructions from one basic block to another,
the debug values are not remapped, in the same was as the
normal instru

[Transforms] Debug values are not remapped when cloning. (#87747)

When cloning instructions from one basic block to another,
the debug values are not remapped, in the same was as the
normal instructions.

show more ...

Revert "[Inline][Cloning] Defer simplification after phi-nodes resolution" #87963

Reopens #87534.

Breaks multiple bots:
https://lab.llvm.org/buildbot/#/builders/168/builds/20028
https://lab.llvm.or

Revert "[Inline][Cloning] Defer simplification after phi-nodes resolution" #87963

Reopens #87534.

Breaks multiple bots:
https://lab.llvm.org/buildbot/#/builders/168/builds/20028
https://lab.llvm.org/buildbot/#/builders/74/builds/27773

And reproducer in a61f9fe31750cee65c726fb51f1b14e31e177258.

This reverts commit a61f9fe31750cee65c726fb51f1b14e31e177258.

show more ...

[Inline][Cloning] Defer simplification after phi-nodes resolution

A logic issue arose when inlining via `CloneAndPruneFunctionInto`,
which, besides cloning, performs instruction simplification as we

[Inline][Cloning] Defer simplification after phi-nodes resolution

A logic issue arose when inlining via `CloneAndPruneFunctionInto`,
which, besides cloning, performs instruction simplification as well.
By the time a new cloned instruction is being simplified, phi-nodes
are not remapped yet as the whole CFG needs to be processed first.
As `VMap` state at this stage is incomplete, `threadCmpOverPHI` and
variants could lead to unsound optimizations. This issue has been
addressed by performing basic constant folding while cloning, and
postponing instruction simplification once phi-nodes are revisited.

Fixes: https://github.com/llvm/llvm-project/issues/87534.

show more ...