[LLVM] Add `Intrinsic::getDeclarationIfExists` (#112428)

Add `Intrinsic::getDeclarationIfExists` to lookup an existing
declaration of an intrinsic in a `Module`.

[RemoveDIs] Make verify-uselistorder preserve the input debug info format (#87789)

Verify-uselistorder wants to take some input IR and verify that the
uselist order is stable after roundtripping to

[RemoveDIs] Make verify-uselistorder preserve the input debug info format (#87789)

Verify-uselistorder wants to take some input IR and verify that the
uselist order is stable after roundtripping to bitcode and assembly.
This is disrupted if the file is converted between the new and old debug
info formats after parsing - while there's no functional difference, the
change to the in-memory representation of the IR modifies the uselist.
This patch changes verify-uselistorder to not convert input files
between debug info formats by default, preventing changes from being
made to the file being checked. In addition, this patch makes it so that
when we _do_ print IR in the new debug info format to bitcode or
assembly, we delete any lingering debug intrinsic declarations, ensuring
that we don't write uselist entries for them.

show more ...

[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 [RemoveDIs] Read/write DbgRecords directly from/to bitcode (#83251)

Reaplying after revert in #85382 (861ebe6446296c96578807363aa292c69d827773).
Fixed intermittent test failure by avoiding p

Reapply [RemoveDIs] Read/write DbgRecords directly from/to bitcode (#83251)

Reaplying after revert in #85382 (861ebe6446296c96578807363aa292c69d827773).
Fixed intermittent test failure by avoiding piping output in some RUN lines.

If --write-experimental-debuginfo-iterators-to-bitcode is true (default false)
and --expermental-debuginfo-iterators is also true then the new debug info
format (non-instruction records) is written to bitcode directly.

Added the following records:

FUNC_CODE_DEBUG_RECORD_LABEL
FUNC_CODE_DEBUG_RECORD_VALUE
FUNC_CODE_DEBUG_RECORD_DECLARE
FUNC_CODE_DEBUG_RECORD_ASSIGN
FUNC_CODE_DEBUG_RECORD_VALUE_SIMPLE

The last one has an abbrev in FUNCTION_BLOCK BLOCK_INFO. Incidentally, this uses
the last value available without widening the code-length for FUNCTION_BLOCK
from 4 to 5 bits.

Records are formatted as follows:

All DbgRecord start with:
1. DILocation

FUNC_CODE_DEBUG_RECORD_LABEL
2. DILabel

DPValues then share common fields:
2. DILocalVariable
3. DIExpression

FUNC_CODE_DEBUG_RECORD_VALUE
4. Location Metadata

FUNC_CODE_DEBUG_RECORD_DECLARE
4. Location Metadata

FUNC_CODE_DEBUG_RECORD_VALUE_SIMPLE
4. Location Value (single)

FUNC_CODE_DEBUG_RECORD_ASSIGN
4. Location Metadata
5. DIAssignID
6. DIExpression (address)
7. Location Metadata (address)

Encoding the DILocation metadata reference directly appeared to yield smaller
bitcode files than encoding the operands seperately (as is done with instruction
DILocations).

FUNC_CODE_DEBUG_RECORD_VALUE_SIMPLE is by far the most common DbgRecord record
in optimized code (order of 5x-10x over other kinds). Unoptimized code should
only contain FUNC_CODE_DEBUG_RECORD_DECLARE.

show more ...

Revert "[RemoveDIs] Read/write DbgRecords directly from/to bitcode" (#85382)

Reverts llvm/llvm-project#83251

Buildbot: https://lab.llvm.org/buildbot/#/builders/139/builds/61485

[RemoveDIs] Read/write DbgRecords directly from/to bitcode (#83251)

If --write-experimental-debuginfo-iterators-to-bitcode is true (default false)
and --expermental-debuginfo-iterators is also true

[RemoveDIs] Read/write DbgRecords directly from/to bitcode (#83251)

If --write-experimental-debuginfo-iterators-to-bitcode is true (default false)
and --expermental-debuginfo-iterators is also true then the new debug info
format (non-instruction records) is written to bitcode directly.

Added the following records:

FUNC_CODE_DEBUG_RECORD_LABEL
FUNC_CODE_DEBUG_RECORD_VALUE
FUNC_CODE_DEBUG_RECORD_DECLARE
FUNC_CODE_DEBUG_RECORD_ASSIGN
FUNC_CODE_DEBUG_RECORD_VALUE_SIMPLE

The last one has an abbrev in FUNCTION_BLOCK BLOCK_INFO. Incidentally, this uses
the last value available without widening the code-length for FUNCTION_BLOCK
from 4 to 5 bits.

Records are formatted as follows:

All DbgRecord start with:
1. DILocation

FUNC_CODE_DEBUG_RECORD_LABEL
2. DILabel

DPValues then share common fields:
2. DILocalVariable
3. DIExpression

FUNC_CODE_DEBUG_RECORD_VALUE
4. Location Metadata

FUNC_CODE_DEBUG_RECORD_DECLARE
4. Location Metadata

FUNC_CODE_DEBUG_RECORD_VALUE_SIMPLE
4. Location Value (single)

FUNC_CODE_DEBUG_RECORD_ASSIGN
4. Location Metadata
5. DIAssignID
6. DIExpression (address)
7. Location Metadata (address)

Encoding the DILocation metadata reference directly appeared to yield smaller
bitcode files than encoding the operands seperately (as is done with instruction
DILocations).

FUNC_CODE_DEBUG_RECORD_VALUE_SIMPLE is by far the most common DbgRecord record
in optimized code (order of 5x-10x over other kinds). Unoptimized code should
only contain FUNC_CODE_DEBUG_RECORD_DECLARE.

show more ...

[DebugInfo][RemoveDIs] Convert back to intrinsic form for ThinLTO

As explained on discourse [0] (comment 12), to get the non-intrinsic form
of debug-info records enabled and testing, we're only usin

[DebugInfo][RemoveDIs] Convert back to intrinsic form for ThinLTO

As explained on discourse [0] (comment 12), to get the non-intrinsic form
of debug-info records enabled and testing, we're only using it inside of
the pass manager in LLVM right now. Things like the textual IR writer and
bitcode writing _passes_ are instrumented to convert back to
intrinsic-form when writing a module out, but it turns out we missed the
ThinLTO bitcode writing pass. That causes uh, all variable location
debug-info to be dropped in ThinLTO mode (oops).

This patch adds that conversion; it should be low risk as it's identical to
what happens in all the other passes. However should this commit turn out
to cause trouble, please instead revert d759618df76 or whichever is the
most recent commit to set UseNewDbgInfoFormat to default to true. That'll
revert LLVM back to the definitely-correct behaviour.

[0] https://discourse.llvm.org/t/rfc-instruction-api-changes-needed-to-eliminate-debug-intrinsics-from-ir/68939

show more ...

[Transforms] Use StringRef::starts_with/ends_with instead of startswith/endswith. NFC.

startswith/endswith wrap starts_with/ends_with and will eventually go away (to more closely match string_view)

[IPO] Remove unnecessary bitcasts (NFC)

[ThinLTOBitcodeWriter] Do not crash on a typed declaration (#69564)

This fixes a crash when `splitAndWriteThinLTOBitcode()` hits a
declaration with type metadata. For example, such declarations can

[ThinLTOBitcodeWriter] Do not crash on a typed declaration (#69564)

This fixes a crash when `splitAndWriteThinLTOBitcode()` hits a
declaration with type metadata. For example, such declarations can be
generated by the `EliminateAvailableExternally` pass.

show more ...

[LTO] Fix -Wunused-variable in -DLLVM_ENABLE_ASSERTIONS=off builds after D123803

[llvm] A Unified LTO Bitcode Frontend

Here's a high level summary of the changes in this patch. For more
information on rational, see the RFC.
(https://discourse.llvm.org/t/rfc-a-unified-lto-bitcode

[llvm] A Unified LTO Bitcode Frontend

Here's a high level summary of the changes in this patch. For more
information on rational, see the RFC.
(https://discourse.llvm.org/t/rfc-a-unified-lto-bitcode-frontend/61774).

- Add config parameter to LTO backend, specifying which LTO mode is
desired when using unified LTO.
- Add unified LTO flag to the summary index for efficiency. Unified
LTO modules can be detected without parsing the module.
- Make sure that the ModuleID is generated by incorporating more types
of symbols.

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

show more ...

Add a type_checked_load_relative to support relative function pointer tables

This adds a type_checked_load_relative intrinsic whose semantics it is to
load a relative function pointer.

A relative f

Add a type_checked_load_relative to support relative function pointer tables

This adds a type_checked_load_relative intrinsic whose semantics it is to
load a relative function pointer.

A relative function pointer is a pointer to a 32bit value that when
added to its address yields the address of the function.

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

show more ...

[ThinLTOBitcodeWriter] Properly report when module is changed

Happens with split LTO units.

Detected with upcoming changes.

Remove several no longer needed includes. NFCI

Mostly removing includes of InitializePasses.h and Pass.h in
passes that no longer has support for the legacy PM.

Fix -fsplit-lto-unit with ifuncs

ifuncs can't take part of the whole-program devirtualization so no need them to be copied to the merged module.
The corresponding resolver function also kept out whi

Fix -fsplit-lto-unit with ifuncs

ifuncs can't take part of the whole-program devirtualization so no need them to be copied to the merged module.
The corresponding resolver function also kept out which caused the crash.

Fixes #60962 #57870

Reviewed By: tejohnson

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

show more ...

[AA] Tracking per-location ModRef info in FunctionModRefBehavior (NFCI)

Currently, FunctionModRefBehavior tracks whether the function reads
or writes memory (ModRefInfo) and which locations it can a

[AA] Tracking per-location ModRef info in FunctionModRefBehavior (NFCI)

Currently, FunctionModRefBehavior tracks whether the function reads
or writes memory (ModRefInfo) and which locations it can access
(argmem, inaccessiblemem and other). This patch changes it to track
ModRef information per-location instead.

To give two examples of why this is useful:

* D117095 highlights a weakness of ModRef modelling in the presence
of operand bundles. For a memcpy call with deopt operand bundle,
we want to say that it can read any memory, but only write argument
memory. This would allow them to be treated like any other calls.
However, we currently can't express this and have to say that it
can read or write any memory.
* D127383 would ideally be modelled as a separate threadid location,
where threadid Refs outside pre-split coroutines can be ignored
(like other accesses to constant memory). The current representation
does not allow modelling this precisely.

The patch as implemented is intended to be NFC, but there are some
obvious opportunities for improvements and simplification. To fully
capitalize on this we would also want to change the way we represent
memory attributes on functions, but that's a larger change, and I
think it makes sense to separate out the FunctionModRefBehavior
refactoring.

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

show more ...

[Transforms] Qualify auto in range-based for loops (NFC)

Identified with readability-qualified-auto.

[LegacyPM] Remove ThinLTO bitcode writer legacy pass

Using the legacy PM for the optimization pipeline is deprecated and in
the process of being removed. This is a small step in that direction.

For

[LegacyPM] Remove ThinLTO bitcode writer legacy pass

Using the legacy PM for the optimization pipeline is deprecated and in
the process of being removed. This is a small step in that direction.

For an example of migrating to the new PM:
https://github.com/llvm/llvm-project/commit/853b57fe80bdb9d6b19697e6f2abc734834e9f6d

show more ...

[WPD] Use new llvm.public.type.test intrinsic for potentially publicly visible classes

Turning on opaque pointers has uncovered an issue with WPD where we currently pattern match away `assume(type.t

[WPD] Use new llvm.public.type.test intrinsic for potentially publicly visible classes

Turning on opaque pointers has uncovered an issue with WPD where we currently pattern match away `assume(type.test)` in WPD so that a later LTT doesn't resolve the type test to undef and introduce an `assume(false)`. The pattern matching can fail in cases where we transform two `assume(type.test)`s into `assume(phi(type.test.1, type.test.2))`.

Currently we create `assume(type.test)` for all virtual calls that might be devirtualized. This is to support `-Wl,--lto-whole-program-visibility`.

To prevent this, all virtual calls that may not be in the same LTO module instead use a new `llvm.public.type.test` intrinsic in place of the `llvm.type.test`. Then when we know if `-Wl,--lto-whole-program-visibility` is passed or not, we can either replace all `llvm.public.type.test` with `llvm.type.test`, or replace all `llvm.public.type.test` with `true`. This prevents WPD from trying to pattern match away `assume(type.test)` for public virtual calls when failing the pattern matching will result in miscompiles.

Reviewed By: tejohnson

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

show more ...

[IPO] Use default member initialization (NFC)

Identified with modernize-use-default-member-init.

Cleanup includes: Transforms/IPO

Preprocessor output diff: -238205 lines
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.ll

Cleanup includes: Transforms/IPO

Preprocessor output diff: -238205 lines
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D122183

show more ...

[FunctionAttrs] Replace MemoryAccessKind with FMRB.

Update FunctionAttrs to use FunctionModRefBehavior instead
MemoryAccessKind.

This allows for adding support for inferring argmemonly and others,

[FunctionAttrs] Replace MemoryAccessKind with FMRB.

Update FunctionAttrs to use FunctionModRefBehavior instead
MemoryAccessKind.

This allows for adding support for inferring argmemonly and others,
see D121415.

Reviewed By: nikic

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

show more ...

[BitcodeWriter] Fix cases of some functions

`WriteIndexToFile` is used by external projects so I do not touch it.