[IR] Avoid repeated hash lookups (NFC) (#112469)

Revert "demangle function names in trace files (#87626)"

This reverts commit 0fa20c55b58deb94090985a5c5ffda4d5ceb3cd1.

Storing raw symbol names is generally preferred in profile files.
Demangling m

Revert "demangle function names in trace files (#87626)"

This reverts commit 0fa20c55b58deb94090985a5c5ffda4d5ceb3cd1.

Storing raw symbol names is generally preferred in profile files.
Demangling might lose information. Language frontends might use
demangling schemes not supported by LLVMDemangle
(https://github.com/llvm/llvm-project/issues/45901#issuecomment-2008686663).
In addition, calling `demangle` for each function has a significant
performance overhead (#102222).

I believe that even if we decide to provide a producer-side demangling,
it would not be on by default.

Pull Request: https://github.com/llvm/llvm-project/pull/102274

show more ...

[LegacyPM] Drop analysis groups (#101670)

This improves the performance of recordAvailableAnalysis and freePass so
that they don't need to call getPassInfo(), which acquires a lock on
every call.

[LegacyPM] Drop analysis groups (#101670)

This improves the performance of recordAvailableAnalysis and freePass so
that they don't need to call getPassInfo(), which acquires a lock on
every call.

The performance-wise interesting part is only in LegacyPassManager.cpp,
everything else is just cleanup.

show more ...

demangle function names in trace files (#87626)

This improves consistency in the trace files as other entries are
demangled too.
Submitted by jamieschmeiser on behalf of trass3r
@jamieschmeiser @

demangle function names in trace files (#87626)

This improves consistency in the trace files as other entries are
demangled too.
Submitted by jamieschmeiser on behalf of trass3r
@jamieschmeiser @An-DJ

show more ...

[IR] Use range-based for loops (NFC) (#97575)

[RemoveDIs][NFC] Use ScopedDbgInfoFormatSetter in more places (#87380)

The class `ScopedDbgInfoFormatSetter` was added as a convenient way to
temporarily change the debug info format of a function

[RemoveDIs][NFC] Use ScopedDbgInfoFormatSetter in more places (#87380)

The class `ScopedDbgInfoFormatSetter` was added as a convenient way to
temporarily change the debug info format of a function or module, as
part of IR printing; since this process is repeated in a number of other
places, this patch uses the format-setter class in those places as well.

show more ...

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

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

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

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

[DebugInfo][RemoveDIs] Add conversion utilities for new-debug-info format

This patch plumbs the command line --experimental-debuginfo-iterators flag
in to the pass managers, so that modules can be c

[DebugInfo][RemoveDIs] Add conversion utilities for new-debug-info format

This patch plumbs the command line --experimental-debuginfo-iterators flag
in to the pass managers, so that modules can be converted to the new
format, passes run, then converted back to the old format. That allows
developers to test-out the new debuginfo representation across some part of
LLVM with no further work, and from the command line. It also installs
flag-catchers at the various points that bitcode and textual IR can egress
from a process, and temporarily convert the module to dbg.value format when
doing so.

No tests alas as it's designed to be transparent.

Differential Revision: https://reviews.llvm.org/D154372

show more ...

[LegacyPM] Reduce number of calls to getName

Repeatedly calling getName adds some overhead, which can be easily
avoided by querying the name just once per function. The improvements
are rather small

[LegacyPM] Reduce number of calls to getName

Repeatedly calling getName adds some overhead, which can be easily
avoided by querying the name just once per function. The improvements
are rather small (~0.5% back-end time in a compile-time optimized
setting), but also very easy to achieve.

Note that getting the name should be entirely avoidable in the common
case, but would require more substantial changes.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D148145

show more ...

[LegacyPM] Call getPassName only when needed

Even when time tracing is disabled, getPassName is currently still
called. This adds an avoidable virtual function call for each pass.
Fetching the pass

[LegacyPM] Call getPassName only when needed

Even when time tracing is disabled, getPassName is currently still
called. This adds an avoidable virtual function call for each pass.
Fetching the pass name only when required slightly improves
compile-time (particularly when LLVM is built without LTO).

Reviewed By: nikic, MaskRay

Differential Revision: https://reviews.llvm.org/D148022

show more ...

[LegacyPassManager] Move structural hashing into Pass classes. NFC.

Move structural hashing into virtual methods on Pass. This will
allow MachineFunctionPass to override the method to add hashing of

[LegacyPassManager] Move structural hashing into Pass classes. NFC.

Move structural hashing into virtual methods on Pass. This will
allow MachineFunctionPass to override the method to add hashing of
the MachineFunction.

Differential Revision: https://reviews.llvm.org/D120123

show more ...

[llvm] Use = default (NFC)

Add missing includes after LLVMCore header cleanup

- conditionally include header only used for expensive check
- have Core.h always include llvm-c/ErrorHandling.h

Cleanup header dependencies in LLVMCore

Based on the output of include-what-you-use.

This is a big chunk of changes. It is very likely to break downstream code
unless they took a lot of care in avo

Cleanup header dependencies in LLVMCore

Based on the output of include-what-you-use.

This is a big chunk of changes. It is very likely to break downstream code
unless they took a lot of care in avoiding hidden ehader dependencies, something
the LLVM codebase doesn't do that well :-/

I've tried to summarize the biggest change below:

- llvm/include/llvm-c/Core.h: no longer includes llvm-c/ErrorHandling.h
- llvm/IR/DIBuilder.h no longer includes llvm/IR/DebugInfo.h
- llvm/IR/IRBuilder.h no longer includes llvm/IR/IntrinsicInst.h
- llvm/IR/LLVMRemarkStreamer.h no longer includes llvm/Support/ToolOutputFile.h
- llvm/IR/LegacyPassManager.h no longer include llvm/Pass.h
- llvm/IR/Type.h no longer includes llvm/ADT/SmallPtrSet.h
- llvm/IR/PassManager.h no longer includes llvm/Pass.h nor llvm/Support/Debug.h

And the usual count of preprocessed lines:
$ clang++ -E -Iinclude -I../llvm/include ../llvm/lib/IR/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l
before: 6400831
after: 6189948

200k lines less to process is no that bad ;-)

Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup

Differential Revision: https://reviews.llvm.org/D118652

show more ...

[llvm] Remove redundant member initialization (NFC)

Identified with readability-redundant-member-init.

Revert "[llvm] Remove redundant member initialization (NFC)"

This reverts commit fd4808887ee47f3ec8a030e9211169ef4fb094c3.

This patch causes gcc to issue a lot of warnings like:

warning: base cl

Revert "[llvm] Remove redundant member initialization (NFC)"

This reverts commit fd4808887ee47f3ec8a030e9211169ef4fb094c3.

This patch causes gcc to issue a lot of warnings like:

warning: base class ‘class llvm::MCParsedAsmOperand’ should be
explicitly initialized in the copy constructor [-Wextra]

show more ...

[llvm] Remove redundant member initialization (NFC)

Identified with readability-redundant-member-init.

[llvm] Use range-based for loops (NFC)

[llvm] Replace report_fatal_error(std::string) uses with report_fatal_error(Twine)

As described on D111049, we're trying to remove the <string> dependency from error handling and replace uses of rep

[llvm] Replace report_fatal_error(std::string) uses with report_fatal_error(Twine)

As described on D111049, we're trying to remove the <string> dependency from error handling and replace uses of report_fatal_error(const std::string&) with the Twine() variant which can be forward declared.

show more ...

[opt] Error if -debug-pass is specified alongside the new PM

Reviewed By: ychen

Differential Revision: https://reviews.llvm.org/D97810

[IR] Use range-based for loops (NFC)

[PM] Show the pass argument in pre/post-pass IR dumps

This patch adds each pass' pass argument in the header for IR dumps.
For example:

Before:

```
*** IR Dump Before InstructionSelect ***
```

[PM] Show the pass argument in pre/post-pass IR dumps

This patch adds each pass' pass argument in the header for IR dumps.
For example:

Before:

```
*** IR Dump Before InstructionSelect ***
```

After:

```
*** IR Dump Before InstructionSelect (instruction-select) ***
```

The goal is to make it easier to know what argument to pass to
command line options like `debug-only` or `run-pass` to further
investigate a given pass.

show more ...