[NFC] Suppress spurious deprecation warning with MSVC (#124764)

gcc and clang won't complain about calls to deprecated functions, if
you're calling from a function that is deprecated too. However,

[NFC] Suppress spurious deprecation warning with MSVC (#124764)

gcc and clang won't complain about calls to deprecated functions, if
you're calling from a function that is deprecated too. However, MSVC
does care, and expands into maaany deprecation warnings for
getFirstNonPHI.

Suppress this by converting the inlineable copy of getFirstNonPHI into a
non-inline copy.

show more ...

[NFC][DebugInfo] Deprecate iterator-taking moveBefore and getFirstNonPHI (#124290)

The RemoveDIs project [0] makes debug intrinsics obsolete and to support
this instruction iterators carry an extra

[NFC][DebugInfo] Deprecate iterator-taking moveBefore and getFirstNonPHI (#124290)

The RemoveDIs project [0] makes debug intrinsics obsolete and to support
this instruction iterators carry an extra bit of debug information. To
maintain debug information accuracy insertion needs to be performed with a
BasicBlock::iterator rather than with Instruction pointers, otherwise the
extra bit of debug information is lost.

To that end, we're deprecating getFirstNonPHI and moveBefore for
instruction pointers. They're replaced by getFirstNonPHIIt and an
iterator-taking moveBefore: switching to the replacement is
straightforwards, and 99% of call-sites need only to unwrap the iterator
with &* or call getIterator() on an Instruction pointer.

The exception is when inserting instructions at the start of a block: if
you call getFirstNonPHI() (or begin() or getFirstInsertionPt()) and then
insert something at that position, you must pass the BasicBlock::iterator
returned into the insertion method. Unwrapping with &* and then calling
getIterator strips the debug-info bit we wish to preserve. Please do
contact us about any use case that's confusing or unclear [1].

[0] https://llvm.org/docs/RemoveDIsDebugInfo.html
[1] https://discourse.llvm.org/t/psa-ir-output-changing-from-debug-intrinsics-to-debug-records/79578

show more ...

[NFC][DebugInfo] Switch more call-sites to using iterator-insertion (#124283)

To finalise the "RemoveDIs" work removing debug intrinsics, we're
updating call sites that insert instructions to use i

[NFC][DebugInfo] Switch more call-sites to using iterator-insertion (#124283)

To finalise the "RemoveDIs" work removing debug intrinsics, we're
updating call sites that insert instructions to use iterators instead.
This set of changes are those where it's not immediately obvious that
just calling getIterator to fetch an iterator is correct, and one or two
places where more than one line needs to change.

Overall the same rule holds though: iterators generated for the start of
a block such as getFirstNonPHIIt need to be passed into insert/move
methods without being unwrapped/rewrapped, everything else can use
getIterator.

show more ...

[NFC][DebugInfo] Make some block-start-position methods return iterators (#124287)

As part of the "RemoveDIs" work to eliminate debug intrinsics, we're
replacing methods that use Instruction*'s as

[NFC][DebugInfo] Make some block-start-position methods return iterators (#124287)

As part of the "RemoveDIs" work to eliminate debug intrinsics, we're
replacing methods that use Instruction*'s as positions with iterators. A
number of these (such as getFirstNonPHIOrDbg) are sufficiently
infrequently used that we can just replace the pointer-returning version
with an iterator-returning version, hopefully without much/any
disruption.

Thus this patch has getFirstNonPHIOrDbg and
getFirstNonPHIOrDbgOrLifetime return an iterator, and updates all
call-sites. There are no concerns about the iterators returned being
converted to Instruction*'s and losing the debug-info bit: because the
methods skip debug intrinsics, the iterator head bit is always false
anyway.

show more ...

[llvm] Remove redundant control flow statements (NFC) (#115831)

Identified with readability-redundant-control-flow.

[RemoveDIs] Fix spliceDebugInfo splice-to-end edge case (#105671)

Fix #105571 which demonstrates an end() iterator dereference when
performing a non-empty splice to end() from a region that ends at

[RemoveDIs] Fix spliceDebugInfo splice-to-end edge case (#105671)

Fix #105571 which demonstrates an end() iterator dereference when
performing a non-empty splice to end() from a region that ends at
Src::end().

Rather than calling Instruction::adoptDbgRecords from Dest, create a marker
(which takes an iterator) and absorbDebugValues onto that. The "absorb" variant
doesn't clean up the source marker, which in this case we know is a trailing
marker, so we have to do that manually.

show more ...

[RemoveDIs] Simplify spliceDebugInfo, fixing splice-to-end edge case (#105670)

Not quite NFC, fixes splitBasicBlockBefore case when we split before an
instruction with debug records (but without th

[RemoveDIs] Simplify spliceDebugInfo, fixing splice-to-end edge case (#105670)

Not quite NFC, fixes splitBasicBlockBefore case when we split before an
instruction with debug records (but without the headBit set, i.e., we are
splitting before the instruction but after the debug records that come before
it). splitBasicBlockBefore splices the instructions before the split point into
a new block. Prior to this patch, the debug records would get shifted up to the
front of the spliced instructions (as seen in the modified unittest - I believe
the unittest was checking erroneous behaviour). We instead want to leave those
debug records at the end of the spliced instructions.

The functionality of the deleted `else if` branch is covered by the remaining
`if` now that `DestMarker` is set to the trailing marker if `Dest` is `end()`.
Previously the "===" markers were sometimes detached, now we always detach
them and always reattach them.

Note: `deleteTrailingDbgRecords` only "unlinks" the tailing marker from the
block, it doesn't delete anything. The trailing marker is still cleaned up
properly inside the final `if` body with `DestMarker->eraseFromParent();`.

Part 1 of 2 needed for #105571

show more ...

[IR] Add per-function numbers to basic blocks (#101052)

Every basic block that is linked into a function now has a unique
number, which can be queried using getNumber(). Numbers are densely
alloca

[IR] Add per-function numbers to basic blocks (#101052)

Every basic block that is linked into a function now has a unique
number, which can be queried using getNumber(). Numbers are densely
allocated, but not re-assigned on block removal for stability. Block
numbers are intended to be fairly stable and only be updated when
removing a several basic blocks to make sure the numbering doesn't
become too sparse.

To reduce holes in the numbering, renumberBlocks() can be called to
re-assign numbers in block order.

Additionally, getMaxBlockNumber() returns a value larger than the
largest block number, intended to pre-allocate/resize vectors.

Furthermore, this introduces the concept of a "block number epoch" --
an integer that changes after every renumbering. This is useful for
identifying use of block numbers after renumbering: on initialization,
the current epoch is stored, and on all subsequent accesses, equality
with the current epoch can be asserted.

I added a validate method to catch cases where something goes wrong,
even if I can't really imagine how invalid numbers can occur. But I
think it's better to be safe and rule out this potential source of bugs
when more things depend on the numbering.

Previous discussion in:
https://discourse.llvm.org/t/rfc-add-auxiliary-field-for-per-pass-custom-data-to-basicblock/80229

show more ...

[llvm] Initialize SmallVector with ranges (NFC) (#100948)

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

[LLVM] Add option to store Parent-pointer in ilist_node_base (#94224)

This patch adds a new option for `ilist`, `ilist_parent<ParentTy>`, that
enables storing an additional pointer in the `ilist_no

[LLVM] Add option to store Parent-pointer in ilist_node_base (#94224)

This patch adds a new option for `ilist`, `ilist_parent<ParentTy>`, that
enables storing an additional pointer in the `ilist_node_base` type to a
specified "parent" type, and uses that option for `Instruction`.

This is distinct from the `ilist_node_with_parent` class, despite their
apparent similarities. The `ilist_node_with_parent` class is a subclass
of `ilist_node` that requires its own subclasses to define a `getParent`
method, which is then used by the owning `ilist` for some of its
operations; it is purely an interface declaration. The `ilist_parent`
option on the other hand is concerned with data, adding a parent field
to the `ilist_node_base` class.

Currently, we can use `BasicBlock::iterator` to insert instructions,
_except_ when either the iterator is invalid (`NodePtr=0x0`), or when
the iterator points to a sentinel value (`BasicBlock::end()`). This patch
results in the sentinel value also having a valid pointer to its owning
basic block, which allows us to use iterators for all insertions,
without needing to store or pass an extra `BasicBlock *BB` argument
alongside it.

show more ...

Reapply#4 "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

Reapplies commit c5aeca73 (and its followup commit 21396be8), which were
reverted due to missing functionality in

Reapply#4 "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

Reapplies commit c5aeca73 (and its followup commit 21396be8), which were
reverted due to missing functionality in MLIR and Flang regarding printing
debug records. This has now been added in commit 08aa511, along with support
for printing debug records in flang.

This reverts commit 2dc2290860355dd2bac3b655eea895fe30fde257.

show more ...

Revert new debug info format commits:

"[Flang] Update test to not check for tail calls on debug intrinsics" &
"Reapply#3 "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

Re

Revert new debug info format commits:

"[Flang] Update test to not check for tail calls on debug intrinsics" &
"Reapply#3 "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

Recent updates to flang have added debug info generation via MLIR, a path
which currently does not support debug records. The patch that enables
debug records by default (and a small followup patch) are thus being
reverted until the MLIR path has been fixed.

This reverts commits:
21396be865b4640abf6afa0b05de6708a1a996e0
c5aeca732d1ff6769b0659efebd1cfb5f60487e4

show more ...

Reapply#3 "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

Reapplies commit 91446e2, which was reverted due to a downstream error,
discussed on the pull request. The error c

Reapply#3 "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

Reapplies commit 91446e2, which was reverted due to a downstream error,
discussed on the pull request. The error could not be reproduced
upstream, and cannot be reproduced downstream as-of current main, so
until the error can be confirmed to still exist this patch should
return.

This reverts commit 23f8fac745bdde70ed4f9c585d19c4913734f1b8.

show more ...

Revert "Repply#2 "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)""

This reverts commit 91446e2aa687ec57ad88dc0df793d0c6e694a7c9 and
a unittest followup 1530f319311908b06fe93

Revert "Repply#2 "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)""

This reverts commit 91446e2aa687ec57ad88dc0df793d0c6e694a7c9 and
a unittest followup 1530f319311908b06fe935c89fca692d3e53184f (#90476).

In a stage-2 -flto=thin -gsplit-dwarf -g -fdebug-info-for-profiling
-fprofile-sample-use= build of clang, a ThinLTO backend compile has
assertion failures:

Global is external, but doesn't have external or weak linkage!
ptr @_ZN5clang12ast_matchers8internal18makeAllOfCompositeINS_8QualTypeEEENS1_15BindableMatcherIT_EEN4llvm8ArrayRefIPKNS1_7MatcherIS5_EEEE
function declaration may only have a unique !dbg attachment
ptr @_ZN5clang12ast_matchers8internal18makeAllOfCompositeINS_8QualTypeEEENS1_15BindableMatcherIT_EEN4llvm8ArrayRefIPKNS1_7MatcherIS5_EEEE

The failures somehow go away if -fprofile-sample-use= is removed.

show more ...

Repply#2 "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

Reapplies the original commit:
2f01fd99eb8c8ab3db9aba72c4f00e31e9e60a05

The previous application of this patch f

Repply#2 "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

Reapplies the original commit:
2f01fd99eb8c8ab3db9aba72c4f00e31e9e60a05

The previous application of this patch failed due to some missing
DbgVariableRecord support in clang, which has been added now by commit
8805465e.

This will probably break some downstream tools that don't already handle
debug records. If your downstream code breaks as a result of this
change, the simplest fix is to convert the module in question to the old
debug format before you process it, using
`Module::convertFromNewDbgValues()`. For more information about how to
handle debug records or about what has changed, see the migration
document:
https://llvm.org/docs/RemoveDIsDebugInfo.html

This reverts commit 4fd319ae273ed6c252f2067909c1abd9f6d97efa.

show more ...

Revert#2 "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

Reverted following probably-causing failures on some clang buildbots:
https://lab.llvm.org/buildbot/#/builders/24

Revert#2 "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

Reverted following probably-causing failures on some clang buildbots:
https://lab.llvm.org/buildbot/#/builders/245/builds/24037

This reverts commit a12622543de15df45fb9ad64e8ab723289d55169.

show more ...

Reapply "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

Fixes the broken tests in the original commit:
2f01fd99eb8c8ab3db9aba72c4f00e31e9e60a05

This will probably break

Reapply "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

Fixes the broken tests in the original commit:
2f01fd99eb8c8ab3db9aba72c4f00e31e9e60a05

This will probably break some downstream tools that don't already handle
debug records. If your downstream code breaks as a result of this
change, the simplest fix is to convert the module in question to the old
debug format before you process it, using
`Module::convertFromNewDbgValues()`. For more information about how to
handle debug records or about what has changed, see the migration
document:
https://llvm.org/docs/RemoveDIsDebugInfo.html

This reverts commit 00821fed09969305b0003d3313c44d1e761a7131.

show more ...

Revert "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

A unit test was broken by the above commit:
https://lab.llvm.org/buildbot/#/builders/139/builds/64627

This reverts

Revert "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

A unit test was broken by the above commit:
https://lab.llvm.org/buildbot/#/builders/139/builds/64627

This reverts commit 2f01fd99eb8c8ab3db9aba72c4f00e31e9e60a05.

show more ...

[RemoveDIs] Load into new debug info format by default in LLVM (#89799)

This patch enables parsing and creating modules directly into the new
debug info format. Prior to this patch, all modules wer

[RemoveDIs] Load into new debug info format by default in LLVM (#89799)

This patch enables parsing and creating modules directly into the new
debug info format. Prior to this patch, all modules were constructed
with the old debug info format by default, and would be converted into
the new format just before running LLVM passes. This is an important
milestone, in that this means that every tool will now be exposed to
debug records, rather than those that run LLVM passes. As far as I've
tested, all LLVM tools/projects now either handle debug records, or
convert them to the old intrinsic format.

There are a few unit tests that need updating for this patch; these are
either cases of tests that previously needed to set the debug info
format to function, or tests that depend on the old debug info format in
some way. There should be no visible change in the output of any LLVM
tool as a result of this patch, although the likelihood of this patch
breaking downstream code means an NFC tag might be a little misleading,
if not technically incorrect:

This will probably break some downstream tools that don't already handle
debug records. If your downstream code breaks as a result of this
change, the simplest fix is to convert the module in question to the old
debug format before you process it, using
`Module::convertFromNewDbgValues()`. For more information about how to
handle debug records or about what has changed, see the migration
document:
https://llvm.org/docs/RemoveDIsDebugInfo.html

show more ...

[RemoveDIs] Fix SIGSEGV caused by splitBasicBlock (#90312)

See `llvm/unittests/IR/BasicBlockDbgInfoTest.cpp` for a test case.

[IR] Use StringRef::operator== instead of StringRef::equals (NFC) (#90550)

I'm planning to remove StringRef::equals in favor of
StringRef::operator==.

- StringRef::operator== outnumbers StringRe

[IR] Use StringRef::operator== instead of StringRef::equals (NFC) (#90550)

I'm planning to remove StringRef::equals in favor of
StringRef::operator==.

- StringRef::operator== outnumbers StringRef::equals by a factor of 22
under llvm/ in terms of their usage.

- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.

- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".

show more ...

[RemoveDIs] Add flag to preserve the debug info format of input IR (#87379)

This patch adds a new flag: `--preserve-input-debuginfo-format`

This flag instructs the tool to not convert the debug i

[RemoveDIs] Add flag to preserve the debug info format of input IR (#87379)

This patch adds a new flag: `--preserve-input-debuginfo-format`

This flag instructs the tool to not convert the debug info format
(intrinsics/records) of input IR, but to instead determine the format of
the input IR and overwrite the other format-determining flags so that we
process and output the file in the same format that we received it in.
This flag is turned off by llvm-link, llvm-lto, and llvm-lto2, and
should be turned off by any other tool that expects to parse multiple IR
modules and have their debug info formats match.

The motivation for this flag is to allow tools to not convert the debug
info format - verify-uselistorder and llvm-reduce, and any downstream
tools that seek to test or mutate IR as-is, without applying extraneous
modifications to the input. This is a necessary step to using debug
records by default in all (other) LLVM tools.

show more ...

[RemoveDIs] Enable direct-to-bitcode writing by default

Follow on from #83251. This patch simply enables the behaviour by default in
order to provide an easily revertible capstone.

[RemoveDIs][NFC] Rename DPMarker->DbgMarker (#85931)

Another trivial rename patch, the last big one for now, which renamed
DPMarkers to DbgMarkers. This required the field `DbgMarker` in
`Instruct

[RemoveDIs][NFC] Rename DPMarker->DbgMarker (#85931)

Another trivial rename patch, the last big one for now, which renamed
DPMarkers to DbgMarkers. This required the field `DbgMarker` in
`Instruction` to be renamed to `DebugMarker` to avoid a clash, but
otherwise was a simple string substitution of `s/DPMarker/DbgMarker` and
a manual renaming of `DPM` to `DM` in the few places where that acronym
was used for debug markers.

show more ...