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

[llvm] Construct SmallVector with ArrayRef (NFC) (#101872)

[NFC] Add DIExpression::calculateFragmentIntersect (#97738)

Patch [3/x] to fix structured bindings debug info in SROA.

This function computes a fragment, bit-extract operation if needed, and new

[NFC] Add DIExpression::calculateFragmentIntersect (#97738)

Patch [3/x] to fix structured bindings debug info in SROA.

This function computes a fragment, bit-extract operation if needed, and new
constant offset to describe a part of a variable covered by some memory.

This generalises, simplifies, and replaces at::calculateFragmentIntersect. That
version is still used as a wrapper for now though to keep this change NFC.

The new version takes doesn't have a DbgRecord parameter, instead using an
explicit address and address offset. The old version only operates on
dbg_assigns and this change means it can also operate on dbg_declare records
easily, which it will do in a subsequent patch.

The new version has a new out-param OffsetFromLocationInBits which is set to
the difference between the first bit of the variable location and the first
bit of the memory slice. This will be used in a subsequent patch in SROA to
determine the new offset to use in the address expression after splitting an
alloca.

show more ...

[NFC] Add DIExpression::extractLeadingOffset (#97719)

Patch [2/x] to fix structured bindings debug info in SROA.

It extracts a constant offset from the DIExpression if there is one and fills
Rem

[NFC] Add DIExpression::extractLeadingOffset (#97719)

Patch [2/x] to fix structured bindings debug info in SROA.

It extracts a constant offset from the DIExpression if there is one and fills
RemainingOps with the ops that come after it.

This function will be used in a subsequent patch.

show more ...

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

[DebugInfo] Handle DW_OP_LLVM_extract_bits in SROA (#94638)

This doesn't need any work to be done in SROA itself, but rather in
functions that it uses. Specifically:
* DIExpression::createFragment

[DebugInfo] Handle DW_OP_LLVM_extract_bits in SROA (#94638)

This doesn't need any work to be done in SROA itself, but rather in
functions that it uses. Specifically:
* DIExpression::createFragmentExpression is made to understand
DW_OP_LLVM_extract_bits
* valueCoversEntireFragment is made to check the active bits instead of
the fragment size, so that it handles extract_bits correctly

show more ...

[DebugInfo] Add DW_OP_LLVM_extract_bits (#93990)

This operation extracts a number of bits at a given offset and sign or
zero extends them, which is done by emitting it as a left shift followed
by

[DebugInfo] Add DW_OP_LLVM_extract_bits (#93990)

This operation extracts a number of bits at a given offset and sign or
zero extends them, which is done by emitting it as a left shift followed
by a right shift.

This is being added for use in clang for C++ structured bindings of
bitfields that have offset or size that aren't a byte multiple. A new
operation is being added, instead of shifts being used directly, as it
makes correctly handling it in optimisations (which will be done in a
later patch) much easier.

show more ...

Use DIExpression::foldConstantMath() at the result of an append() (#71719)

This patch uses `DIExpression::foldConstantMath()` at the end of a
`DIExpression::append()`. Which should help in reducing

Use DIExpression::foldConstantMath() at the result of an append() (#71719)

This patch uses `DIExpression::foldConstantMath()` at the end of a
`DIExpression::append()`. Which should help in reducing the size of
DIExpressions that grow because of salvaging debug info

This is part of a stack of patches and comes after:
https://github.com/llvm/llvm-project/pull/69768
https://github.com/llvm/llvm-project/pull/71717
https://github.com/llvm/llvm-project/pull/71718

show more ...

Introduce DIExpression::foldConstantMath() (#71718)

DIExpressions can get very long and have a lot of redundant operations.
This function uses simple pattern matching to fold constant math that
ca

Introduce DIExpression::foldConstantMath() (#71718)

DIExpressions can get very long and have a lot of redundant operations.
This function uses simple pattern matching to fold constant math that
can be evaluated at compile time.

The hope is that other people can contribute other patterns as well.

I also couldn't see a good way of combining this with
`DIExpression::constantFold` so it stands alone.

This is part of a stack of patches and comes after
https://github.com/llvm/llvm-project/pull/69768
https://github.com/llvm/llvm-project/pull/71717

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

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

[DebugInfo] Fix faulty DIExpression::appendToStack assert (#85255)

The appendToStack() function asserts that no DW_OP_stack_value or
DW_OP_LLVM_fragment operations are present in the operations to b

[DebugInfo] Fix faulty DIExpression::appendToStack assert (#85255)

The appendToStack() function asserts that no DW_OP_stack_value or
DW_OP_LLVM_fragment operations are present in the operations to be
appended. The function did that by iterating over all elements in the
array rather than just the operations, leading it to falsely asserting
on the following input produced by getExt(), since 159 (0x9f) is the
DWARF code for DW_OP_stack_value:

{dwarf::DW_OP_LLVM_convert, 159, dwarf::DW_ATE_signed}

Fix this by using expr_op iterators.

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

[HWASAN] Remove DW_OP_LLVM_tag_offset from DIExpression::isImplicit (#79816)

According to its doc-comment `isImplicit` is meant to return true if the
expression is an implicit location description

[HWASAN] Remove DW_OP_LLVM_tag_offset from DIExpression::isImplicit (#79816)

According to its doc-comment `isImplicit` is meant to return true if the
expression is an implicit location description (describes an object or part of
an object which has no location by computing the value from available program
state).

There's a brief entry for `DW_OP_LLVM_tag_offset` in the LangRef and there's
some info in the original commit fb9ce100d19be130d004d03088ccd4af295f3435.

From what I can tell it doesn't look like `DW_OP_LLVM_tag_offset` affects
whether or not the location is implicit; the opcode doesn't get included in the
final location description but instead is added as an attribute to the variable.

This was tripping an assertion in the latest application of the fix to #76545,
#78606, where an expression containing a `DW_OP_LLVM_tag_offset` is split into
a fragment (i.e., describe a part of the whole variable).

show more ...

[DebugInfo][RemoveDIs] Instrument loop-rotate for DPValues (#72997)

Loop-rotate manually maintains dbg.value intrinsics -- it also needs to
manually maintain the replacement for dbg.value intrinsic

[DebugInfo][RemoveDIs] Instrument loop-rotate for DPValues (#72997)

Loop-rotate manually maintains dbg.value intrinsics -- it also needs to
manually maintain the replacement for dbg.value intrinsics, DPValue
objects. For the most part this patch adds parallel implementations
using the new type Some extra juggling is needed when loop-rotate hoists
loop-invariant instructions out of the loop: the DPValues attached to
such an instruction need to get rotated but not hoisted. Exercised by
the new test function invariant_hoist in dbgvalue.ll.

There's also a "don't insert duplicate debug intrinsics" facility in
LoopRotate. The value and correctness of this isn't clear, but to
continue preserving behaviour that's now tested in the "tak_dup"
function in dbgvalue.ll.

Other things in this patch include a helper DebugVariable constructor
for DPValues, a insertDebugValuesForPHIs handler for RemoveDIs
(exercised by the new tests), and beefing up the dbg.value checking in
dbgvalue.ll to ensure that each record is tested (and that there's an
implicit check-not).

show more ...

Reapply "[DebugInfo] Make DIArgList inherit from Metadata and always unique"

This reverts commit 0fd5dc94380d5fe666dc6c603b4bb782cef743e7.

The original commit removed DIArgLists from being in an MD

Reapply "[DebugInfo] Make DIArgList inherit from Metadata and always unique"

This reverts commit 0fd5dc94380d5fe666dc6c603b4bb782cef743e7.

The original commit removed DIArgLists from being in an MDNode map, but did
not insert a new `delete` in the LLVMContextImpl destructor. This
reapply adds that call to delete, preventing a memory leak.

show more ...

Revert "[DebugInfo] Make DIArgList inherit from Metadata and always unique" (#72682)

Reverts llvm/llvm-project#72147

Reverted due to buildbot failure:
https://lab.llvm.org/buildbot/#/builders/5/

Revert "[DebugInfo] Make DIArgList inherit from Metadata and always unique" (#72682)

Reverts llvm/llvm-project#72147

Reverted due to buildbot failure:
https://lab.llvm.org/buildbot/#/builders/5/builds/38410

show more ...

[DebugInfo] Make DIArgList inherit from Metadata and always unique (#72147)

This patch changes the `DIArgList` class's inheritance from `MDNode` to
`Metadata, ReplaceableMetadataImpl`, and ensures

[DebugInfo] Make DIArgList inherit from Metadata and always unique (#72147)

This patch changes the `DIArgList` class's inheritance from `MDNode` to
`Metadata, ReplaceableMetadataImpl`, and ensures that it is always
unique, i.e. a distinct DIArgList should never be produced.

This should not result in any changes to IR or bitcode parsing and
printing, as the format for DIArgList is unchanged, and the order in which it
appears should also be identical. As a minor note, this patch also fixes
a gap in the verifier, where the ValueAsMetadata operands to a DIArgList
would not be visited.

show more ...

[llvm] Reduce memory footprint of Debug metadata nodes (#71227)

Using a combination of reordering fields and using empty SubclassData32
/ SubclassData1, it's possible to improve the size of data st

[llvm] Reduce memory footprint of Debug metadata nodes (#71227)

Using a combination of reordering fields and using empty SubclassData32
/ SubclassData1, it's possible to improve the size of data structures
used to store debug info in the IR:

Before:

DILexicalBlock: 24
DILexicalBlockFile: 24
DIModule: 24
DITemplateParameter: 24
DICommonBlock: 24
DIMacro: 24
DICompileUnit: 56
DIType: 48
DINamespace: 24
DIVariable: 24
DIGlobalVariable: 32
DILocalVariable: 32
DILabel: 24

After:

DILexicalBlock: 24
DILexicalBlockFile: 16
DIModule: 16
DITemplateParameter: 16
DICommonBlock: 16
DIMacro: 16
DICompileUnit: 48
DIType: 40
DINamespace: 16
DIVariable: 24
DIGlobalVariable: 24
DILocalVariable: 32
DILabel: 16

show more ...

Reland "[llvm][DebugInfo] DWARFv5: static data members declarations are DW_TAG_variable (#72234)"

This was reverted because it broke the OCaml LLVM bindings.
Relanding the original patch but without

Reland "[llvm][DebugInfo] DWARFv5: static data members declarations are DW_TAG_variable (#72234)"

This was reverted because it broke the OCaml LLVM bindings.
Relanding the original patch but without changing the C-API.
They'll continue to work just fine as they do today. If in the
future there is a need to pass a new tag to the C-API for creating
static members, then we'll make the change to the OCaml bindings
at that time.

Original commit message:
"""
This patch adds the LLVM-side infrastructure to implement DWARFv5 issue
161118.1: "DW_TAG for C++ static data members".

The clang-side of this patch will simply construct the DIDerivedType
with a different DW_TAG.
"""

show more ...

Revert "[llvm][DebugInfo] DWARFv5: static data members declarations are DW_TAG_variable (#72234)"

This reverts commit 9a9933fae23249fbf6cf5b3c090e630f578b7f98.

The OCaml bindings were using `LLVMDI

Revert "[llvm][DebugInfo] DWARFv5: static data members declarations are DW_TAG_variable (#72234)"

This reverts commit 9a9933fae23249fbf6cf5b3c090e630f578b7f98.

The OCaml bindings were using `LLVMDIBuilderCreateStaticMemberType`,
causing the API change in `9a9933fae23249fbf6cf5b3c090e630f578b7f98`
to break buildbots that built the bindings. Revert until we figure out
whether to fixup the bindings or just not change the C-API

show more ...