[DebugInfo] Add a specification attribute to LLVM DebugInfo (#115362)

Add a specification attribute to LLVM DebugInfo, which is analogous
to DWARF's DW_AT_specification. According to the DWARF spec

[DebugInfo] Add a specification attribute to LLVM DebugInfo (#115362)

Add a specification attribute to LLVM DebugInfo, which is analogous
to DWARF's DW_AT_specification. According to the DWARF spec:
"A debugging information entry that represents a declaration that
completes another (earlier) non-defining declaration may have a
DW_AT_specification attribute whose value is a reference to the
debugging information entry representing the non-defining declaration."

This patch allows types to be specifications of other types. This is
used by Swift to represent generic types. For example, given this Swift
program:

```
struct MyStruct<T> {
let t: T
}

let variable = MyStruct<Int>(t: 43)
```

The Swift compiler emits (roughly) an unsubtituted type for MyStruct<T>:
```
DW_TAG_structure_type
DW_AT_name ("MyStruct")
// "$s1w8MyStructVyxGD" is a Swift mangled name roughly equivalent to
// MyStruct<T>
DW_AT_linkage_name ("$s1w8MyStructVyxGD")
// other attributes here
```
And a specification for MyStruct<Int>:
```
DW_TAG_structure_type
DW_AT_specification (<link to "MyStruct">)
// "$s1w8MyStructVySiGD" is a Swift mangled name equivalent to
// MyStruct<Int>
DW_AT_linkage_name ("$s1w8MyStructVySiGD")
DW_AT_byte_size (0x08)
// other attributes here
```

show more ...

[DebugInfo] Add num_extra_inhabitants to debug info (#112590)

An extra inhabitant is a bit pattern that does not represent a valid
value for instances of a given type. The number of extra inhabitan

[DebugInfo] Add num_extra_inhabitants to debug info (#112590)

An extra inhabitant is a bit pattern that does not represent a valid
value for instances of a given type. The number of extra inhabitants is
the number of those bit configurations.

This is used by Swift to save space when composing types. For example,
because Bool only needs 2 bit patterns to represent all of its values
(true and false), an Optional<Bool> only occupies 1 byte in memory by
using a bit configuration that is unused by Bool. Which bit patterns are
unused are part of the ABI of the language.

Since Swift generics are not monomorphized, by using dynamic libraries
you can have generic types whose size, alignment, etc, are known only
at runtime (which is why this feature is needed).

This patch adds num_extra_inhabitants to LLVM-IR debug info and in DWARF
as an Apple extension.

show more ...

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

[Bitcode] Avoid repeated hash lookups (NFC) (#107708)

[Bitcode] Use range-based for loops (NFC) (#97776)

Revert "[DebugInfo][BPF] Add 'annotations' field for DIBasicType & DI… (#96172)

…SubroutineType (#91422)"

This reverts commit 3ca17443ef4af21bdb1f3b4fbcfff672cbc6176c.

As reported in [1,2] the

Revert "[DebugInfo][BPF] Add 'annotations' field for DIBasicType & DI… (#96172)

…SubroutineType (#91422)"

This reverts commit 3ca17443ef4af21bdb1f3b4fbcfff672cbc6176c.

As reported in [1,2] the commit above causes CI failure for powerpc-aix
target.
There is also a performance regression reported in [3]. Reverting to
comply with the developer policy.

[1]
https://github.com/llvm/llvm-project/pull/91422#issuecomment-2179425473
[2] https://lab.llvm.org/buildbot/#/builders/64/builds/62
[3]
https://github.com/llvm/llvm-project/pull/91422#issuecomment-2175631443

show more ...

[DebugInfo][BPF] Add 'annotations' field for DIBasicType & DISubroutineType (#91422)

Extend `DIBasicType` and `DISubroutineType` with additional field
`annotations`, e.g. as below:

```
!5 = !

[DebugInfo][BPF] Add 'annotations' field for DIBasicType & DISubroutineType (#91422)

Extend `DIBasicType` and `DISubroutineType` with additional field
`annotations`, e.g. as below:

```
!5 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed, annotations: !6)
!6 = !{!7}
!7 = !{!"btf:type_tag", !"tag1"}
```

The field would be used by BPF backend to generate DWARF attributes
corresponding to `btf_type_tag` type attributes, e.g.:

```
0x00000029: DW_TAG_base_type
DW_AT_name ("int")
DW_AT_encoding (DW_ATE_signed)
DW_AT_byte_size (0x04)

0x0000002d: DW_TAG_LLVM_annotation
DW_AT_name ("btf:type_tag")
DW_AT_const_value ("tag1")
```

Such DWARF entries would be used to generate BTF definitions by tools
like [pahole](https://github.com/acmel/dwarves).

Note: similar fields with similar purposes are already present in
DIDerivedType and DICompositeType.

Currently "btf_type_tag" attributes are represented in debug information
as 'annotations' fields in DIDerivedType with DW_TAG_pointer_type tag.
The annotation on a pointer corresponds to pointee having the attributes
in the final BTF.

The discussion in
[thread](https://lore.kernel.org/bpf/87r0w9jjoq.fsf@oracle.com/) came to
conclusion, that such annotations should apply to the annotated type
itself. Hence the necessity to extend `DIBasicType` & `DISubroutineType`
types with 'annotations' field to represent cases like below:

```
int __attribute__((btf_type_tag("foo"))) bar;
```

This was previously tracked as differential revision:
https://reviews.llvm.org/D143966

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

[RemoveDIs] Auto-upgrade debug intrinsics to DbgRecords (default false) (#85650)

If --load-bitcode-into-experimental-debuginfo-iterators is true then debug
intrinsics are auto-upgraded to DbgRecord

[RemoveDIs] Auto-upgrade debug intrinsics to DbgRecords (default false) (#85650)

If --load-bitcode-into-experimental-debuginfo-iterators is true then debug
intrinsics are auto-upgraded to DbgRecords (the new debug info format).

The upgrade is trivial because the two representations are semantically
identical. llvm.dbg.value with 4 operands and llvm.dbg.addr intrinsics are
upgraded in the same way as usual, but converted directly into DbgRecords
instead of debug intrinsics.

show more ...

[Dwarf] Support `__ptrauth` qualifier in metadata nodes (#83862)

Reland #82363 after fixing build failure
https://lab.llvm.org/buildbot/#/builders/5/builds/41428.

Memory sanitizer detects usage

[Dwarf] Support `__ptrauth` qualifier in metadata nodes (#83862)

Reland #82363 after fixing build failure
https://lab.llvm.org/buildbot/#/builders/5/builds/41428.

Memory sanitizer detects usage of `RawData` union member which is not
filled directly. Instead, the code relies on filling `Data` union
member, which is a struct consisting of signing schema parameters.

According to https://en.cppreference.com/w/cpp/language/union, this is
UB:
"It is undefined behavior to read from the member of the union that
wasn't most recently written".

Instead of relying on compiler allowing us to do dirty things, do not
use union and only store `RawData`. Particular ptrauth parameters are
obtained on demand via bit operations.

Original PR description below.

Emit `__ptrauth`-qualified types as `DIDerivedType` metadata nodes in IR
with tag `DW_TAG_LLVM_ptrauth_type`, baseType referring to the type
which has the qualifier applied, and the following parameters
representing the signing schema:

- `ptrAuthKey` (integer)
- `ptrAuthIsAddressDiscriminated` (boolean)
- `ptrAuthExtraDiscriminator` (integer)
- `ptrAuthIsaPointer` (boolean)
- `ptrAuthAuthenticatesNullValues` (boolean)

Co-authored-by: Ahmed Bougacha <ahmed@bougacha.org>

show more ...

Revert "[Dwarf] Support `__ptrauth` qualifier in metadata nodes" (#83672)

Reverts llvm/llvm-project#82363

See a build failure related to an issue discovered by memory sanitizer
(use of uninitial

Revert "[Dwarf] Support `__ptrauth` qualifier in metadata nodes" (#83672)

Reverts llvm/llvm-project#82363

See a build failure related to an issue discovered by memory sanitizer
(use of uninitialized value):
https://lab.llvm.org/buildbot/#/builders/37/builds/31965

show more ...

[Dwarf] Support `__ptrauth` qualifier in metadata nodes (#82363)

Emit `__ptrauth`-qualified types as `DIDerivedType` metadata nodes in IR
with tag `DW_TAG_LLVM_ptrauth_type`, baseType referring to

[Dwarf] Support `__ptrauth` qualifier in metadata nodes (#82363)

Emit `__ptrauth`-qualified types as `DIDerivedType` metadata nodes in IR
with tag `DW_TAG_LLVM_ptrauth_type`, baseType referring to the type
which has the qualifier applied, and the following parameters
representing the signing schema:

- `ptrAuthKey` (integer)
- `ptrAuthIsAddressDiscriminated` (boolean)
- `ptrAuthExtraDiscriminator` (integer)
- `ptrAuthIsaPointer` (boolean)
- `ptrAuthAuthenticatesNullValues` (boolean)

Co-authored-by: Ahmed Bougacha <ahmed@bougacha.org>

show more ...

[ThinLTO][DebugInfo] Emit full type definitions when importing anonymous types. (#78461)

This fixes some cases of missing debuginfo caused by an interaction
between:


https://github.com/llvm/ll

[ThinLTO][DebugInfo] Emit full type definitions when importing anonymous types. (#78461)

This fixes some cases of missing debuginfo caused by an interaction
between:


https://github.com/llvm/llvm-project/commit/f0d66559ea345db4b2116cae044aaf3399d7e829,
which drops the identifier from a DICompositeType in the module
containing its
vtable.

and


https://github.com/llvm/llvm-project/commit/a61f5e379675732666744bcba25efbc9922e016a,
which causes ThinLTO to import composite types as declarations when they
have
an identifier.

If a virtual class's DICompositeType has no identifier due to the first
change,
and contains a nested anonymous type which does have an identifier, then
the
second change can cause ThinLTO to output the classes's DICompositeType
as a
type definition that links to a non-defining declaration for the nested
type.
Since the nested anonyous type does not have a name, debuggers are
unable to
find the definition for the declaration.

Repro case:
```
cat > a.h <<EOF
class A {
public:
A();
virtual ~A();

private:
union {
int val;
};
};
EOF

cat > a.cc <<EOF
#include "a.h"

A::A() { asm(""); }

A::~A() {}
EOF

cat > main.cc <<EOF
#include "a.h"

int main(int argc, char **argv) {
A a;
return 0;
}
EOF

clang++ -O2 -g -flto=thin -mllvm -force-import-all main.cc a.cc
gdb ./a.out -batch -ex 'pt /rmt A'
```

The gdb command outputs:
```
type = class A {
private:
union {
<incomplete type>
};
}
```

and dwarfdump -i a.out shows a DW_TAG_class_type for A with an
incomplete union
type (note that there is also a duplicate entry with the full union type
that
comes after).
```
< 1><0x0000001e> DW_TAG_class_type
DW_AT_containing_type <0x0000001e>
DW_AT_calling_convention DW_CC_pass_by_reference
DW_AT_name (indexed string: 0x00000007)A
DW_AT_byte_size 0x00000010
DW_AT_decl_file 0x00000001 /path/to/./a.h
DW_AT_decl_line 0x00000001
...
< 2><0x0000002f> DW_TAG_member
DW_AT_type <0x00000037>
DW_AT_decl_file 0x00000001 /path/to/./a.h
DW_AT_decl_line 0x00000007
DW_AT_data_member_location 8
< 2><0x00000037> DW_TAG_union_type
DW_AT_export_symbols yes(1)
DW_AT_calling_convention DW_CC_pass_by_value
DW_AT_declaration yes(1)
```

This change works around this by making ThinLTO always import full
definitions
for anonymous types.

show more ...

Revert "[CloneFunction][DebugInfo] Avoid cloning DILocalVariables of inlined functions (#75385)"

This reverts commit fc6faa1113e9069f41b5500db051210af0eea843.

[CloneFunction][DebugInfo] Avoid cloning DILocalVariables of inlined functions (#75385)

- [DebugMetadata][DwarfDebug] Support function-local types in lexical
block scopes (4/7)
- [CloneFunction][Deb

[CloneFunction][DebugInfo] Avoid cloning DILocalVariables of inlined functions (#75385)

- [DebugMetadata][DwarfDebug] Support function-local types in lexical
block scopes (4/7)
- [CloneFunction][DebugInfo] Avoid cloning DILocalVariables of inlined
functions

This is a follow-up for https://reviews.llvm.org/D144006, fixing a crash
reported
in Chromium (https://reviews.llvm.org/D144006#4651955).

The first commit is added for convenience, as it has already been
accepted.

If DISubpogram was not cloned (e.g. we are cloning a function that has
other
functions inlined into it, and subprograms of the inlined functions are
not supposed to be cloned), it doesn't make sense to clone its
DILocalVariables as well.
Otherwise get duplicated DILocalVariables not tracked in their
subprogram's retainedNodes, that crash LTO with Chromium.

This is meant to be committed along with
https://reviews.llvm.org/D144006.

show more ...

[llvm] Use StringRef::{starts,ends}_with (NFC) (#74956)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::

[llvm] Use StringRef::{starts,ends}_with (NFC) (#74956)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

show more ...

Revert "[DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (4/7)"

This caused assert:
llvm/llvm/lib/CodeGen/AsmPrinter/DwarfFile.cpp:110:
void llvm::DwarfFile::addScope

Revert "[DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (4/7)"

This caused assert:
llvm/llvm/lib/CodeGen/AsmPrinter/DwarfFile.cpp:110:
void llvm::DwarfFile::addScopeVariable(LexicalScope *, DbgVariable *):
Assertion `Ret.second' failed.

See comments https://reviews.llvm.org/D144006#4656350.

This reverts commit 3b449bd46a11a55a40cbc0016a99b202fa05248e.

show more ...

[DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (4/7)

RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-loc

[DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (4/7)

RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544

Similar to imported declarations, the patch tracks function-local types in
DISubprogram's 'retainedNodes' field. DwarfDebug is adjusted in accordance with
the aforementioned metadata change and provided a support of function-local
types scoped within a lexical block.

The patch assumes that DICompileUnit's 'enums field' no longer tracks local
types and DwarfDebug would assert if any locally-scoped types get placed there.

Reviewed By: jmmartinez
Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com>
Differential Revision: https://reviews.llvm.org/D144006

show more ...

[llvm] Stop including llvm/ADT/iterator_range.h (NFC)

Identified with misc-include-cleaner.

[DebugInfo] Only call upgradeCULocals() at module level (#68965)

Loading a 2GB bitcode file, I noticed that we spend minutes just running
upgradeCULocals(). Apparently it gets invoked every time a

[DebugInfo] Only call upgradeCULocals() at module level (#68965)

Loading a 2GB bitcode file, I noticed that we spend minutes just running
upgradeCULocals(). Apparently it gets invoked every time a metadata
block is loaded, which will be once at the module level and then once
per function. However, the relevant metadata only exists at the module
level, so running this upgrade per function is unnecessary.

show more ...

[BitcodeReader] Replace unsupported constexprs in metadata with undef

Metadata (via ValueAsMetadata) can reference constant expressions
that may no longer be supported. These references can both be

[BitcodeReader] Replace unsupported constexprs in metadata with undef

Metadata (via ValueAsMetadata) can reference constant expressions
that may no longer be supported. These references can both be in
function-local metadata and module metadata, if the same expression
is used in multiple functions. At least in theory, such references
could also be in metadata proper, rather than just inside
ValueAsMetadata references in calls.

Instead of trying to expand these expressions (which we can't
reliably do), pretend that the constant has been deleted, which
means that ValueAsMetadata references will get replaced with
undef metadata.

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

show more ...

Revert "[DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (4/7)"

This caused asserts:

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:2331:
virtual void llvm::DwarfDeb

Revert "[DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (4/7)"

This caused asserts:

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:2331:
virtual void llvm::DwarfDebug::endFunctionImpl(const llvm::MachineFunction *):
Assertion `LScopes.getAbstractScopesList().size() == NumAbstractSubprograms &&
"getOrCreateAbstractScope() inserted an abstract subprogram scope"' failed.

See comment on the code review for reproducer.

> RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544
>
> Similar to imported declarations, the patch tracks function-local types in
> DISubprogram's 'retainedNodes' field. DwarfDebug is adjusted in accordance with
> the aforementioned metadata change and provided a support of function-local
> types scoped within a lexical block.
>
> The patch assumes that DICompileUnit's 'enums field' no longer tracks local
> types and DwarfDebug would assert if any locally-scoped types get placed there.
>
> Reviewed By: jmmartinez
>
> Differential Revision: https://reviews.llvm.org/D144006

This reverts commit f8aab289b5549086062588fba627b0e4d3a5ab15.

show more ...

[Bitcode] Support expanding constant expressions in function metadata

This fixes the bitcode upgrade failure reported in
https://reviews.llvm.org/D155924#4616789.

The expansion always happens in th

[Bitcode] Support expanding constant expressions in function metadata

This fixes the bitcode upgrade failure reported in
https://reviews.llvm.org/D155924#4616789.

The expansion always happens in the entry block, so this may be
inaccurate if there are trapping constant expressions.

show more ...

[DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (4/7)

RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-loc

[DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (4/7)

RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544

Similar to imported declarations, the patch tracks function-local types in
DISubprogram's 'retainedNodes' field. DwarfDebug is adjusted in accordance with
the aforementioned metadata change and provided a support of function-local
types scoped within a lexical block.

The patch assumes that DICompileUnit's 'enums field' no longer tracks local
types and DwarfDebug would assert if any locally-scoped types get placed there.

Reviewed By: jmmartinez

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

show more ...

[Bitcode] Add some missing GetTypeByID failure checks

Print an error instead of crashing.

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