History log of /llvm-project/llvm/lib/IR/DebugInfo.cpp (Results 1 – 25 of 507)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init
# a5fb2bbb 18-Jan-2025 Michael Buch <michaelbuch12@gmail.com>

Reapply "[clang][DebugInfo] Emit DW_AT_object_pointer on function declarations with explicit `this`" (#123455)

This reverts commit c3a935e3f967f8f22f5db240d145459ee621c1e0.

The only change to the r

Reapply "[clang][DebugInfo] Emit DW_AT_object_pointer on function declarations with explicit `this`" (#123455)

This reverts commit c3a935e3f967f8f22f5db240d145459ee621c1e0.

The only change to the reverted commit is that this also updates
the OCaml bindings according to the C debug-info API changes.

The build failure originally introduced was:
```
FAILED: bindings/ocaml/debuginfo/debuginfo_ocaml.o /b/1/llvm-clang-x86_64-expensive-checks-debian/build/bindings/ocaml/debuginfo/debuginfo_ocaml.o
cd /b/1/llvm-clang-x86_64-expensive-checks-debian/build/bindings/ocaml/debuginfo && /usr/bin/ocamlfind ocamlc -c /b/1/llvm-clang-x86_64-expensive-checks-debian/build/bindings/ocaml/debuginfo/debuginfo_ocaml.c -ccopt "-I/b/1/llvm-clang-x86_64-expensive-checks-debian/llvm-project/llvm/bindings/ocaml/debuginfo/../llvm -D_GNU_SOURCE -D_DEBUG -D_GLIBCXX_ASSERTIONS -DEXPENSIVE_CHECKS -D_GLIBCXX_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/b/1/llvm-clang-x86_64-expensive-checks-debian/build/include -I/b/1/llvm-clang-x86_64-expensive-checks-debian/llvm-project/llvm/include -DNDEBUG "
/b/1/llvm-clang-x86_64-expensive-checks-debian/build/bindings/ocaml/debuginfo/debuginfo_ocaml.c: In function ‘llvm_dibuild_create_object_pointer_type’:
/b/1/llvm-clang-x86_64-expensive-checks-debian/build/bindings/ocaml/debuginfo/debuginfo_ocaml.c:620:30: error: too few arguments to function ‘LLVMDIBuilderCreateObjectPointerType’
620 | LLVMMetadataRef Metadata = LLVMDIBuilderCreateObjectPointerType(
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /b/1/llvm-clang-x86_64-expensive-checks-debian/build/bindings/ocaml/debuginfo/debuginfo_ocaml.c:23:
/b/1/llvm-clang-x86_64-expensive-checks-debian/llvm-project/llvm/include/llvm-c/DebugInfo.h:880:17: note: declared here
880 | LLVMMetadataRef LLVMDIBuilderCreateObjectPointerType(LLVMDIBuilderRef Builder,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```

show more ...


# c3a935e3 18-Jan-2025 Michał Górny <mgorny@gentoo.org>

Revert "[clang][DebugInfo] Emit DW_AT_object_pointer on function declarations with explicit `this`" (#123455)

Reverts llvm/llvm-project#122928


# 10fdd09c 17-Jan-2025 Michael Buch <michaelbuch12@gmail.com>

[clang][DebugInfo] Emit DW_AT_object_pointer on function declarations with explicit `this` (#122928)

In https://github.com/llvm/llvm-project/pull/122897 we started attaching
`DW_AT_object_pointer`

[clang][DebugInfo] Emit DW_AT_object_pointer on function declarations with explicit `this` (#122928)

In https://github.com/llvm/llvm-project/pull/122897 we started attaching
`DW_AT_object_pointer` to function definitions. This patch does the same
but for function declarations (which we do for implicit object pointers
already).

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

show more ...


Revision tags: llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4
# 5b19ed8b 10-Nov-2024 Kazu Hirata <kazu@google.com>

[llvm] Migrate away from PointerUnion::{is,get,dyn_cast} (NFC) (#115626)

Note that PointerUnion::{is,get,dyn_cast} have been soft deprecated in
PointerUnion.h:

// FIXME: Replace the uses of is

[llvm] Migrate away from PointerUnion::{is,get,dyn_cast} (NFC) (#115626)

Note that PointerUnion::{is,get,dyn_cast} have been soft deprecated in
PointerUnion.h:

// FIXME: Replace the uses of is(), get() and dyn_cast() with
// isa<T>, cast<T> and the llvm::dyn_cast<T>

show more ...


Revision tags: llvmorg-19.1.3
# f23bdbba 28-Oct-2024 tf2spi <misomosispi@gmail.com>

Add DILabel functions for LLVM-C (#112840)

Addresses #112799


Revision tags: llvmorg-19.1.2, llvmorg-19.1.1
# e03f4271 19-Sep-2024 Jay Foad <jay.foad@amd.com>

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


Revision tags: llvmorg-19.1.0, llvmorg-19.1.0-rc4
# 359c7040 22-Aug-2024 Shubham Sandeep Rastogi <srastogi22@apple.com>

Handle #dbg_values in SROA. (#94070)

This patch properly handles #dbg_values in SROA by making sure that any
#dbg_values get moved to before a store just like #dbg_declares do, or
the #dbg_value i

Handle #dbg_values in SROA. (#94070)

This patch properly handles #dbg_values in SROA by making sure that any
#dbg_values get moved to before a store just like #dbg_declares do, or
the #dbg_value is correctly updated with the right alloca after an
aggregate alloca is broken up.

The issue stems from swift where #dbg_values are emitted and not
dbg.declares, the SROA pass doesn't handle the #dbg_values correctly and
it causes them to all have undefs

If we look at this simple-ish testcase (This is all I could reduce it
down to, and I am still relatively bad at writing llvm IR by hand so I
apologize in advance):

```
%T4main1TV13TangentVectorV = type <{ %T4main1UV13TangentVectorV, [7 x i8], %T4main1UV13TangentVectorV }>
%T4main1UV13TangentVectorV = type <{ %T1M1SVySfG, [7 x i8], %T4main1VV13TangentVectorV }>
%T1M1SVySfG = type <{ ptr, %Ts4Int8V }>
%Ts4Int8V = type <{ i8 }>
%T4main1VV13TangentVectorV = type <{ %T1M1SVySfG }>
define hidden swiftcc void @"$s4main1TV13TangentVectorV1poiyA2E_AEtFZ"(ptr noalias nocapture sret(%T4main1TV13TangentVectorV) %0, ptr noalias nocapture dereferenceable(57) %1, ptr noalias nocapture dereferenceable(57) %2) #0 !dbg !44 {
entry:
%3 = alloca %T4main1VV13TangentVectorV
%4 = alloca %T4main1UV13TangentVectorV
%5 = alloca %T4main1VV13TangentVectorV
%6 = alloca %T4main1UV13TangentVectorV
%7 = alloca %T4main1VV13TangentVectorV
%8 = alloca %T4main1UV13TangentVectorV
%9 = alloca %T4main1VV13TangentVectorV
%10 = alloca %T4main1UV13TangentVectorV
call void @llvm.lifetime.start.p0(i64 9, ptr %3)
call void @llvm.lifetime.start.p0(i64 25, ptr %4)
call void @llvm.lifetime.start.p0(i64 9, ptr %5)
call void @llvm.lifetime.start.p0(i64 25, ptr %6)
call void @llvm.lifetime.start.p0(i64 9, ptr %7)
call void @llvm.lifetime.start.p0(i64 25, ptr %8)
call void @llvm.lifetime.start.p0(i64 9, ptr %9)
call void @llvm.lifetime.start.p0(i64 25, ptr %10)
%.u1 = getelementptr inbounds %T4main1TV13TangentVectorV, ptr %1, i32 0, i32 0
call void @llvm.memcpy.p0.p0.i64(ptr align 8 %4, ptr align 8 %.u1, i64 25, i1 false)
%.u11 = getelementptr inbounds %T4main1TV13TangentVectorV, ptr %2, i32 0, i32 0
call void @llvm.memcpy.p0.p0.i64(ptr align 8 %6, ptr align 8 %.u11, i64 25, i1 false)
call void @llvm.dbg.value(metadata ptr %4, metadata !62, metadata !DIExpression(DW_OP_deref)), !dbg !75
%.s = getelementptr inbounds %T4main1UV13TangentVectorV, ptr %4, i32 0, i32 0
%.s.c = getelementptr inbounds %T1M1SVySfG, ptr %.s, i32 0, i32 0
%11 = load ptr, ptr %.s.c
%.s.b = getelementptr inbounds %T1M1SVySfG, ptr %.s, i32 0, i32 1
%.s.b._value = getelementptr inbounds %Ts4Int8V, ptr %.s.b, i32 0, i32 0
%12 = load i8, ptr %.s.b._value
%.s2 = getelementptr inbounds %T4main1UV13TangentVectorV, ptr %6, i32 0, i32 0
%.s2.c = getelementptr inbounds %T1M1SVySfG, ptr %.s2, i32 0, i32 0
%13 = load ptr, ptr %.s2.c
%.s2.b = getelementptr inbounds %T1M1SVySfG, ptr %.s2, i32 0, i32 1
%.s2.b._value = getelementptr inbounds %Ts4Int8V, ptr %.s2.b, i32 0, i32 0
%14 = load i8, ptr %.s2.b._value
%.v = getelementptr inbounds %T4main1UV13TangentVectorV, ptr %4, i32 0, i32 2
call void @llvm.memcpy.p0.p0.i64(ptr align 8 %3, ptr align 8 %.v, i64 9, i1 false)
%.v3 = getelementptr inbounds %T4main1UV13TangentVectorV, ptr %6, i32 0, i32 2
call void @llvm.memcpy.p0.p0.i64(ptr align 8 %5, ptr align 8 %.v3, i64 9, i1 false)
%.s4 = getelementptr inbounds %T4main1VV13TangentVectorV, ptr %3, i32 0, i32 0
%.s4.c = getelementptr inbounds %T1M1SVySfG, ptr %.s4, i32 0, i32 0
%18 = load ptr, ptr %.s4.c
%.s5 = getelementptr inbounds %T4main1VV13TangentVectorV, ptr %5, i32 0, i32 0
%.s5.c = getelementptr inbounds %T1M1SVySfG, ptr %.s5, i32 0, i32 0
%20 = load ptr, ptr %.s5.c
%.u2 = getelementptr inbounds %T4main1TV13TangentVectorV, ptr %1, i32 0, i32 2
call void @llvm.memcpy.p0.p0.i64(ptr align 8 %8, ptr align 8 %.u2, i64 25, i1 false)
%.u26 = getelementptr inbounds %T4main1TV13TangentVectorV, ptr %2, i32 0, i32 2
call void @llvm.memcpy.p0.p0.i64(ptr align 8 %10, ptr align 8 %.u26, i64 25, i1 false)
%.s7 = getelementptr inbounds %T4main1UV13TangentVectorV, ptr %8, i32 0, i32 0
%.s7.c = getelementptr inbounds %T1M1SVySfG, ptr %.s7, i32 0, i32 0
%25 = load ptr, ptr %.s7.c
%.s7.b = getelementptr inbounds %T1M1SVySfG, ptr %.s7, i32 0, i32 1
%.s7.b._value = getelementptr inbounds %Ts4Int8V, ptr %.s7.b, i32 0, i32 0
%26 = load i8, ptr %.s7.b._value
%.s8 = getelementptr inbounds %T4main1UV13TangentVectorV, ptr %10, i32 0, i32 0
%.s8.c = getelementptr inbounds %T1M1SVySfG, ptr %.s8, i32 0, i32 0
%27 = load ptr, ptr %.s8.c
%.s8.b = getelementptr inbounds %T1M1SVySfG, ptr %.s8, i32 0, i32 1
%.s8.b._value = getelementptr inbounds %Ts4Int8V, ptr %.s8.b, i32 0, i32 0
%28 = load i8, ptr %.s8.b._value
%.v9 = getelementptr inbounds %T4main1UV13TangentVectorV, ptr %8, i32 0, i32 2
call void @llvm.memcpy.p0.p0.i64(ptr align 8 %7, ptr align 8 %.v9, i64 9, i1 false)
%.v10 = getelementptr inbounds %T4main1UV13TangentVectorV, ptr %10, i32 0, i32 2
call void @llvm.memcpy.p0.p0.i64(ptr align 8 %9, ptr align 8 %.v10, i64 9, i1 false)
%.s11 = getelementptr inbounds %T4main1VV13TangentVectorV, ptr %7, i32 0, i32 0
%.s11.c = getelementptr inbounds %T1M1SVySfG, ptr %.s11, i32 0, i32 0
%32 = load ptr, ptr %.s11.c
%.s12 = getelementptr inbounds %T4main1VV13TangentVectorV, ptr %9, i32 0, i32 0
%.s12.c = getelementptr inbounds %T1M1SVySfG, ptr %.s12, i32 0, i32 0
%34 = load ptr, ptr %.s12.c
call void @llvm.lifetime.end.p0(i64 25, ptr %10)
call void @llvm.lifetime.end.p0(i64 9, ptr %9)
call void @llvm.lifetime.end.p0(i64 25, ptr %8)
call void @llvm.lifetime.end.p0(i64 9, ptr %7)
call void @llvm.lifetime.end.p0(i64 25, ptr %6)
call void @llvm.lifetime.end.p0(i64 9, ptr %5)
call void @llvm.lifetime.end.p0(i64 25, ptr %4)
call void @llvm.lifetime.end.p0(i64 9, ptr %3)
ret void
}
!llvm.module.flags = !{!0, !1, !2, !3, !4, !6, !7, !8, !9, !10, !11, !12, !13, !14, !15}
!swift.module.flags = !{!33}
!llvm.linker.options = !{!34, !35, !36, !37, !38, !39, !40, !41, !42, !43}
!0 = !{i32 2, !"SDK Version", [2 x i32] [i32 14, i32 4]}
!1 = !{i32 1, !"Objective-C Version", i32 2}
!2 = !{i32 1, !"Objective-C Image Info Version", i32 0}
!3 = !{i32 1, !"Objective-C Image Info Section", !"__DATA, no_dead_strip"}
!4 = !{i32 1, !"Objective-C Garbage Collection", i8 0}
!6 = !{i32 7, !"Dwarf Version", i32 4}
!7 = !{i32 2, !"Debug Info Version", i32 3}
!8 = !{i32 1, !"wchar_size", i32 4}
!9 = !{i32 8, !"PIC Level", i32 2}
!10 = !{i32 7, !"uwtable", i32 1}
!11 = !{i32 7, !"frame-pointer", i32 1}
!12 = !{i32 1, !"Swift Version", i32 7}
!13 = !{i32 1, !"Swift ABI Version", i32 7}
!14 = !{i32 1, !"Swift Major Version", i8 6}
!15 = !{i32 1, !"Swift Minor Version", i8 0}
!16 = distinct !DICompileUnit(language: DW_LANG_Swift, file: !17, imports: !18, sdk: "MacOSX14.4.sdk")
!17 = !DIFile(filename: "/Users/emilpedersen/swift2/swift/test/IRGen/debug_scope_distinct.swift", directory: "/Users/emilpedersen/swift2")
!18 = !{!19, !21, !23, !25, !27, !29, !31}
!19 = !DIImportedEntity(tag: DW_TAG_imported_module, scope: !17, entity: !20, file: !17)
!20 = !DIModule(scope: null, name: "main", includePath: "/Users/emilpedersen/swift2/swift/test/IRGen")
!21 = !DIImportedEntity(tag: DW_TAG_imported_module, scope: !17, entity: !22, file: !17)
!22 = !DIModule(scope: null, name: "Swift", includePath: "/Users/emilpedersen/swift2/_build/Ninja-RelWithDebInfoAssert+stdlib-RelWithDebInfo/swift-macosx-arm64/lib/swift/macosx/Swift.swiftmodule/arm64-apple-macos.swiftmodule")
!23 = !DIImportedEntity(tag: DW_TAG_imported_module, scope: !17, entity: !24, line: 60)
!24 = !DIModule(scope: null, name: "_Differentiation", includePath: "/Users/emilpedersen/swift2/_build/Ninja-RelWithDebInfoAssert+stdlib-RelWithDebInfo/swift-macosx-arm64/lib/swift/macosx/_Differentiation.swiftmodule/arm64-apple-macos.swiftmodule")
!25 = !DIImportedEntity(tag: DW_TAG_imported_module, scope: !17, entity: !26, line: 61)
!26 = !DIModule(scope: null, name: "M", includePath: "/Users/emilpedersen/swift2/_build/Ninja-RelWithDebInfoAssert+stdlib-RelWithDebInfo/swift-macosx-arm64/test-macosx-arm64/IRGen/Output/debug_scope_distinct.swift.tmp/M.swiftmodule")
!27 = !DIImportedEntity(tag: DW_TAG_imported_module, scope: !17, entity: !28, file: !17)
!28 = !DIModule(scope: null, name: "_StringProcessing", includePath: "/Users/emilpedersen/swift2/_build/Ninja-RelWithDebInfoAssert+stdlib-RelWithDebInfo/swift-macosx-arm64/lib/swift/macosx/_StringProcessing.swiftmodule/arm64-apple-macos.swiftmodule")
!29 = !DIImportedEntity(tag: DW_TAG_imported_module, scope: !17, entity: !30, file: !17)
!30 = !DIModule(scope: null, name: "_SwiftConcurrencyShims", includePath: "/Users/emilpedersen/swift2/_build/Ninja-RelWithDebInfoAssert+stdlib-RelWithDebInfo/swift-macosx-arm64/lib/swift/shims")
!31 = !DIImportedEntity(tag: DW_TAG_imported_module, scope: !17, entity: !32, file: !17)
!32 = !DIModule(scope: null, name: "_Concurrency", includePath: "/Users/emilpedersen/swift2/_build/Ninja-RelWithDebInfoAssert+stdlib-RelWithDebInfo/swift-macosx-arm64/lib/swift/macosx/_Concurrency.swiftmodule/arm64-apple-macos.swiftmodule")
!33 = !{i1 false}
!34 = !{!"-lswiftCore"}
!35 = !{!"-lswift_StringProcessing"}
!36 = !{!"-lswift_Differentiation"}
!37 = !{!"-lswiftDarwin"}
!38 = !{!"-lswift_Concurrency"}
!39 = !{!"-lswiftSwiftOnoneSupport"}
!40 = !{!"-lobjc"}
!41 = !{!"-lswiftCompatibilityConcurrency"}
!42 = !{!"-lswiftCompatibility56"}
!43 = !{!"-lswiftCompatibilityPacks"}
!44 = distinct !DISubprogram( unit: !16, declaration: !52, retainedNodes: !53)
!45 = !DIFile(filename: "<compiler-generated>", directory: "/")
!46 = !DICompositeType(tag: DW_TAG_structure_type, scope: !47, elements: !48, identifier: "$s4main1TV13TangentVectorVD")
!47 = !DICompositeType(tag: DW_TAG_structure_type, identifier: "$s4main1TVD")
!48 = !{}
!49 = !DISubroutineType(types: !50)
!50 = !{!51}
!51 = !DICompositeType(tag: DW_TAG_structure_type, identifier: "$s4main1TV13TangentVectorVXMtD")
!52 = !DISubprogram( file: !45, type: !49, spFlags: DISPFlagOptimized)
!53 = !{!54, !56, !57}
!54 = !DILocalVariable( scope: !44, type: !55, flags: DIFlagArtificial)
!55 = !DIDerivedType(tag: DW_TAG_const_type, baseType: !46)
!56 = !DILocalVariable( scope: !44, flags: DIFlagArtificial)
!57 = !DILocalVariable( scope: !44, type: !58, flags: DIFlagArtificial)
!58 = !DIDerivedType(tag: DW_TAG_const_type, baseType: !51)
!62 = !DILocalVariable( scope: !63, type: !72, flags: DIFlagArtificial)
!63 = distinct !DISubprogram( type: !66, unit: !16, declaration: !69, retainedNodes: !70)
!64 = !DICompositeType(tag: DW_TAG_structure_type, scope: !65, identifier: "$s4main1UV13TangentVectorVD")
!65 = !DICompositeType(tag: DW_TAG_structure_type, identifier: "$s4main1UVD")
!66 = !DISubroutineType(types: !67)
!67 = !{!68}
!68 = !DICompositeType(tag: DW_TAG_structure_type, identifier: "$s4main1UV13TangentVectorVXMtD")
!69 = !DISubprogram( spFlags: DISPFlagOptimized)
!70 = !{!71, !73}
!71 = !DILocalVariable( scope: !63, flags: DIFlagArtificial)
!72 = !DIDerivedType(tag: DW_TAG_const_type, baseType: !64)
!73 = !DILocalVariable( scope: !63, type: !74, flags: DIFlagArtificial)
!74 = !DIDerivedType(tag: DW_TAG_const_type, baseType: !68)
!75 = !DILocation( scope: !63, inlinedAt: !76)
!76 = distinct !DILocation( scope: !44)

```

if we run
` opt -S -passes=sroa file.ll -o -`

With this patch we will see
```
%.sroa.5.sroa.021 = alloca [7 x i8], align 8
tail call void @llvm.dbg.value(metadata ptr %.sroa.5.sroa.021, metadata !59, metadata !DIExpression(DW_OP_deref, DW_OP_LLVM_fragment, 72, 56)), !dbg !72
%.sroa.5.sroa.014 = alloca [7 x i8], align 8
```

Without this patch we will see:

```
%.sroa.5.sroa.021 = alloca [7 x i8], align 8
%.sroa.5.sroa.014 = alloca [7 x i8], align 8
```

Thus this patch ensures that llvm.dbg.values that use allocas that are broken up still have the correct metadata and debug information is preserved

This is part of a stack of patches and is preceded by: https://github.com/llvm/llvm-project/pull/94068

show more ...


Revision tags: llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init
# 7a7d3707 12-Jul-2024 Orlando Cazalet-Hyams <orlando.hyams@sony.com>

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


# 9df71d76 28-Jun-2024 Nikita Popov <npopov@redhat.com>

[IR] Add getDataLayout() helpers to Function and GlobalValue (#96919)

Similar to https://github.com/llvm/llvm-project/pull/96902, this adds
`getDataLayout()` helpers to Function and GlobalValue, re

[IR] Add getDataLayout() helpers to Function and GlobalValue (#96919)

Similar to https://github.com/llvm/llvm-project/pull/96902, this adds
`getDataLayout()` helpers to Function and GlobalValue, replacing the
current `getParent()->getDataLayout()` pattern.

show more ...


# db394edf 18-Jun-2024 Carlos Alberto Enciso <Carlos.Enciso@sony.com>

[RemoveDIs] Update DIBuilder C API with DbgRecord functions. (#95535)

The DIBuilder C API was changed to deal with DbgRecord functions:

https://github.com/llvm/llvm-project/pull/84915
https://gi

[RemoveDIs] Update DIBuilder C API with DbgRecord functions. (#95535)

The DIBuilder C API was changed to deal with DbgRecord functions:

https://github.com/llvm/llvm-project/pull/84915
https://github.com/llvm/llvm-project/pull/85657
https://github.com/llvm/llvm-project/pull/92417#issuecomment-2120078326

As discussed by @nikic and @OCHyams:

https://github.com/llvm/llvm-project/pull/92417#issuecomment-2144505440

> For the intrinsic-inserting functions, do you think we should:
>
> a) mark as deprecated but otherwise leave them alone for now.
> b) mark as deprecated and change their behaviour so that they
> do nothing and return nullptr.
> c) outright delete them (it sounds like you're voting this one,
> but just wanted to double check).

This patch implements option (c).

show more ...


Revision tags: llvmorg-18.1.8
# d4a01549 13-Jun-2024 Jay Foad <jay.foad@amd.com>

[llvm-project] Fix typo "seperate" (#95373)


Revision tags: llvmorg-18.1.7, llvmorg-18.1.6
# 91d7ca90 13-May-2024 Orlando Cazalet-Hyams <orlando.hyams@sony.com>

[DebugInfo] Remap extracted DIAssignIDs in hotcoldsplit (#91940)

Fix #91814

When instructions are extracted into a new function the `DIAssignID` metadata
uses and attachments need to be remapped

[DebugInfo] Remap extracted DIAssignIDs in hotcoldsplit (#91940)

Fix #91814

When instructions are extracted into a new function the `DIAssignID` metadata
uses and attachments need to be remapped so that the stores and assignment
markers don't link to stores and assignment markers in the original function.

This matches existing inlining behaviour for DIAssignIDs.

show more ...


Revision tags: llvmorg-18.1.5
# 09e7d86b 30-Apr-2024 Orlando Cazalet-Hyams <orlando.hyams@sony.com>

[RemoveDIs] Fix findDbgValues to return dbg_assign records too (#90471)

In the debug intrinsic class heirachy, a dbg.assign is a (inherits from)
dbg.value, so `findDbgValues` returns dbg.values and

[RemoveDIs] Fix findDbgValues to return dbg_assign records too (#90471)

In the debug intrinsic class heirachy, a dbg.assign is a (inherits from)
dbg.value, so `findDbgValues` returns dbg.values and dbg.assigns (by
design). That hierarchy doesn't exist for DbgRecords - fix findDbgValues
to return dbg_assign records as well as dbg_values and add unittest.

show more ...


Revision tags: llvmorg-18.1.4, llvmorg-18.1.3
# 2a2fd488 28-Mar-2024 Orlando Cazalet-Hyams <orlando.hyams@sony.com>

[RemoveDIs] Update DIBuilder C API and OCaml bindings [2/2] (#86529)

Follow on from #84915 which adds the DbgRecord function variants. The C API
changes were reviewed in #85657.

# C API

Updat

[RemoveDIs] Update DIBuilder C API and OCaml bindings [2/2] (#86529)

Follow on from #84915 which adds the DbgRecord function variants. The C API
changes were reviewed in #85657.

# C API

Update the LLVMDIBuilderInsert... functions to insert DbgRecords instead
of debug intrinsics.

LLVMDIBuilderInsertDeclareBefore
LLVMDIBuilderInsertDeclareAtEnd
LLVMDIBuilderInsertDbgValueBefore
LLVMDIBuilderInsertDbgValueAtEnd

Calling these functions will now cause an assertion if the module is in the
wrong debug info format. They should only be used when the module is in "new
debug format".

Use LLVMIsNewDbgInfoFormat to query and LLVMSetIsNewDbgInfoFormat to change the
debug info format of a module.

Please see https://llvm.org/docs/RemoveDIsDebugInfo.html#c-api-change
(RemoveDIsDebugInfo.md) for more info.

# OCaml bindings

Add set_is_new_dbg_info_format and is_new_dbg_info_format to the OCaml bindings.
These can be used to set and query the current debug info mode. These will
eventually be removed, but are useful while we're transitioning between old and
new debug info formats.

Add string_of_lldbgrecord, like string_of_llvalue but prints DbgRecords.

In test dbginfo.ml, unconditionally set the module debug info to the new mode
and update CHECK lines to check for DbgRecords. Without this change the test
crashes because it attempts to insert DbgRecords (new default behaviour of
llvm_dibuild_insert_declare_...) into a module that is in the old debug info
mode.

show more ...


# 26857582 22-Mar-2024 Orlando Cazalet-Hyams <orlando.hyams@sony.com>

Revert "[RemoveDIs] Update DIBuilder C API with DbgRecord functions [2/2] (#85657)"

This reverts commit 2091c74796b1dac68e622284c63a870b88b7554f.

Builtbot failure: https://lab.llvm.org/buildbot/#/b

Revert "[RemoveDIs] Update DIBuilder C API with DbgRecord functions [2/2] (#85657)"

This reverts commit 2091c74796b1dac68e622284c63a870b88b7554f.

Builtbot failure: https://lab.llvm.org/buildbot/#/builders/16/builds/63080

show more ...


# 2091c747 22-Mar-2024 Orlando Cazalet-Hyams <orlando.hyams@sony.com>

[RemoveDIs] Update DIBuilder C API with DbgRecord functions [2/2] (#85657)

Follow on from #84915 which adds the DbgRecord function variants.

Update the LLVMDIBuilderInsert... functions to insert

[RemoveDIs] Update DIBuilder C API with DbgRecord functions [2/2] (#85657)

Follow on from #84915 which adds the DbgRecord function variants.

Update the LLVMDIBuilderInsert... functions to insert DbgRecords instead
of debug intrinsics.

LLVMDIBuilderInsertDeclareBefore
LLVMDIBuilderInsertDeclareAtEnd
LLVMDIBuilderInsertDbgValueBefore
LLVMDIBuilderInsertDbgValueAtEnd

Calling these functions will now cause an assertion if the module is in the
wrong debug info format. They should only be used when the module is in "new
debug format".

Use LLVMIsNewDbgInfoFormat to query and LLVMSetIsNewDbgInfoFormat to change the
debug info format of a module.

Please see https://llvm.org/docs/RemoveDIsDebugInfo.html#c-api-change
(RemoveDIsDebugInfo.md) for more info.

show more ...


Revision tags: llvmorg-18.1.2
# ffd08c77 19-Mar-2024 Stephen Tozer <stephen.tozer@sony.com>

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


# 924a1dce 19-Mar-2024 Daniil Kovalev <dkovalev@accesssoftek.com>

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


# f0dbcfe3 18-Mar-2024 Orlando Cazalet-Hyams <orlando.hyams@sony.com>

[RemoveDIs] Update DIBuilder C API with DbgRecord functions [1/2] (#84915)

Follow on from #84739, which updates the DIBuilder class.

All the functions that have been added are temporary and will

[RemoveDIs] Update DIBuilder C API with DbgRecord functions [1/2] (#84915)

Follow on from #84739, which updates the DIBuilder class.

All the functions that have been added are temporary and will be
deprecated in the future. The intention is that they'll help downstream
projects adapt during the transition period.

```
New functions (all to be deprecated)
------------------------------------
LLVMIsNewDbgInfoFormat # Returns true if the module is in the new non-instruction mode.
LLVMSetIsNewDbgInfoFormat # Convert to the requested debug info format.

LLVMDIBuilderInsertDeclareIntrinsicBefore # Insert a debug intrinsic (old debug info format).
LLVMDIBuilderInsertDeclareIntrinsicAtEnd # Same as above.
LLVMDIBuilderInsertDbgValueIntrinsicBefore # Same as above.
LLVMDIBuilderInsertDbgValueIntrinsicAtEnd # Same as above.

LLVMDIBuilderInsertDeclareRecordBefore # Insert a debug record (new debug info format).
LLVMDIBuilderInsertDeclareRecordAtEnd # Same as above.
LLVMDIBuilderInsertDbgValueRecordBefore # Same as above.
LLVMDIBuilderInsertDbgValueRecordAtEnd # Same as above.
```

The existing `LLVMDIBuilderInsert...` functions call through to the
intrinsic versions (old debug info format) currently.

In the next patch, I'll swap them to call the debug records versions
(new debug info format). Downstream users of this API can query and
change the current format using the first two functions above, or can
instead opt to temporarily use intrinsics or records explicitly.

show more ...


# 2e865353 14-Mar-2024 Stephen Tozer <stephen.tozer@sony.com>

[RemoveDIs][NFC] Move DPValue::filter -> filterDbgVars (#85208)

This patch changes DPValue::filter to be a non-member method
filterDbgVars. There are two reasons for this: firstly, the name of
DPV

[RemoveDIs][NFC] Move DPValue::filter -> filterDbgVars (#85208)

This patch changes DPValue::filter to be a non-member method
filterDbgVars. There are two reasons for this: firstly, the name of
DPValue is about to change to DbgVariableRecord, which will result in
every `for` loop that uses DPValue::filter to require a line break. This
is a small thing, but it makes the rename patch more difficult to
review, and is just generally more awkward for what is a fairly common
loop. Secondly, the intent is to later break up the DPValue class into
subclasses, at which point it would be better to have a non-member
function that allows template arguments for the cases we want to filter
with greater specificity.

show more ...


# 360da838 13-Mar-2024 Stephen Tozer <stephen.tozer@sony.com>

[RemoveDI][NFC] Rename DPValue->DbgRecord in comments and varnames (#84939)

This patch continues the ongoing rename work, replacing DPValue with
DbgRecord in comments and the names of variables, bo

[RemoveDI][NFC] Rename DPValue->DbgRecord in comments and varnames (#84939)

This patch continues the ongoing rename work, replacing DPValue with
DbgRecord in comments and the names of variables, both members and
fn-local. This is the most labour-intensive part of the rename, as it is
where the most decisions have to be made about whether a given comment
or variable is referring to DPValues (equivalent to debug variable
intrinsics) or DbgRecords (a catch-all for all debug intrinsics); these
decisions are not individually difficult, but comprise a fairly large
amount of text to review.

This patch still largely performs basic string substitutions followed by
clang-format; there are almost* no places where, for example, a comment
has been expanded or modified to reflect the semantic difference between
DPValues and DbgRecords. I don't believe such a change is generally
necessary in LLVM, but it may be useful in the docs, and so I'll be
submitting docs changes as a separate patch.

*In a few places, `dbg.values` was replaced with `debug intrinsics`.

show more ...


# 15f3f446 12-Mar-2024 Stephen Tozer <stephen.tozer@sony.com>

[RemoveDIs][NFC] Rename common interface functions for DPValues->DbgRecords (#84793)

As part of the effort to rename the DbgRecord classes, this patch
renames the widely-used functions that operate

[RemoveDIs][NFC] Rename common interface functions for DPValues->DbgRecords (#84793)

As part of the effort to rename the DbgRecord classes, this patch
renames the widely-used functions that operate on DbgRecords but refer
to DbgValues or DPValues in their names to refer to DbgRecords instead;
all such functions are defined in one of `BasicBlock.h`,
`Instruction.h`, and `DebugProgramInstruction.h`.

This patch explicitly does not change the names of any comments or
variables, except for where they use the exact name of one of the
renamed functions. The reason for this is reviewability; this patch can
be trivially examined to determine that the only changes are direct
string substitutions and any results from clang-format responding to the
changed line lengths. Future patches will cover renaming variables and
comments, and then renaming the classes themselves.

show more ...


# 9997e039 12-Mar-2024 Orlando Cazalet-Hyams <orlando.hyams@sony.com>

[RemoveDIs] Update DIBuilder to conditionally insert DbgRecords (#84739)

Have DIBuilder conditionally insert either debug intrinsics or DbgRecord
depending on the module's IsNewDbgInfoFormat flag.

[RemoveDIs] Update DIBuilder to conditionally insert DbgRecords (#84739)

Have DIBuilder conditionally insert either debug intrinsics or DbgRecord
depending on the module's IsNewDbgInfoFormat flag. The insertion methods
now return a `DbgInstPtr` (a `PointerUnion<Instruction *, DbgRecord
*>`).

Add a unittest for both modes (I couldn't find an existing test testing
insertion behaviours specifically).

This patch changes the existing assumption that DbgRecords are only ever
inserted if there's an instruction to insert-before because clang
currently inserts debug intrinsics while CodeGening (like any other
instruction) meaning it'll try inserting to the end of a block without a
terminator. We already have machinery in place to maintain the
DbgRecords when a terminator is removed - these become "trailing
DbgRecords" which are re-attached when a new instruction is inserted.
All I've done is allow this state to occur while inserting DbgRecords
too, i.e., it's not only removing terminators that causes this valid
transient state, but inserting DbgRecords into incomplete blocks too.

The C API will be updated in follow up patches.

---

Note: this doesn't mean clang is emitting DbgRecords yet, because the
modules it creates are still always in the old debug mode. That will
come in a future patch.

show more ...


Revision tags: llvmorg-18.1.1
# bf08d028 02-Mar-2024 Daniil Kovalev <dkovalev@accesssoftek.com>

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


# 8f65e7b9 01-Mar-2024 Daniil Kovalev <dkovalev@accesssoftek.com>

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


12345678910>>...21