https://github.com/jmorse closed
https://github.com/llvm/llvm-project/pull/144383
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse updated
https://github.com/llvm/llvm-project/pull/144383
>From 63654fb7cf702a1d0c5fb5f8d526e926ec5a3470 Mon Sep 17 00:00:00 2001
From: Jeremy Morse
Date: Fri, 13 Jun 2025 15:39:53 +0100
Subject: [PATCH 1/2] [DebugInfo][RemoveDIs] Suppress
getNextNonDebugInfoInstructio
https://github.com/jmorse updated
https://github.com/llvm/llvm-project/pull/144383
>From 63654fb7cf702a1d0c5fb5f8d526e926ec5a3470 Mon Sep 17 00:00:00 2001
From: Jeremy Morse
Date: Fri, 13 Jun 2025 15:39:53 +0100
Subject: [PATCH] [DebugInfo][RemoveDIs] Suppress
getNextNonDebugInfoInstruction
T
@@ -0,0 +1,160 @@
+# Key Instructions debug info in LLVM and Clang
+
+Key Instructions is an LLVM feature that reduces the jumpiness of optimized
code debug stepping by discriminating the significance of instrucions that make
up source language statements. This document explains
@@ -0,0 +1,160 @@
+# Key Instructions debug info in LLVM and Clang
+
+Key Instructions is an LLVM feature that reduces the jumpiness of optimized
code debug stepping by discriminating the significance of instrucions that make
up source language statements. This document explains
@@ -0,0 +1,160 @@
+# Key Instructions debug info in LLVM and Clang
+
+Key Instructions is an LLVM feature that reduces the jumpiness of optimized
code debug stepping by discriminating the significance of instrucions that make
up source language statements. This document explains
https://github.com/jmorse commented:
Soft LGTM, awaiting views from @jryans too
https://github.com/llvm/llvm-project/pull/137991
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/137991
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jmorse wrote:
Well, github has thrown away my review comments again, so I've no idea 🤷 .
Phabricator was better.
https://github.com/llvm/llvm-project/pull/137991
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma
https://github.com/jmorse closed
https://github.com/llvm/llvm-project/pull/148657
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse created
https://github.com/llvm/llvm-project/pull/148657
Clang can chose which sort of source-file hash is attached to a DIFile metadata
node. However, whenever hashing is possible, we /always/ attach a hash. This
patch permits users who want DWARF5 but don't want the
@@ -0,0 +1,114 @@
+# Key Instructions debug info in LLVM
+
+Key Instructions reduces the jumpiness of optimized code debug stepping. This
document explains the feature and how it is implemented in LLVM. For Clang
support please see the [Clang docs](../../clang/docs/KeyInstructio
@@ -0,0 +1,114 @@
+# Key Instructions debug info in LLVM
+
+Key Instructions reduces the jumpiness of optimized code debug stepping. This
document explains the feature and how it is implemented in LLVM. For Clang
support please see the [Clang docs](../../clang/docs/KeyInstructio
@@ -0,0 +1,114 @@
+# Key Instructions debug info in LLVM
+
+Key Instructions reduces the jumpiness of optimized code debug stepping. This
document explains the feature and how it is implemented in LLVM. For Clang
support please see the [Clang docs](../../clang/docs/KeyInstructio
@@ -0,0 +1,114 @@
+# Key Instructions debug info in LLVM
+
+Key Instructions reduces the jumpiness of optimized code debug stepping. This
document explains the feature and how it is implemented in LLVM. For Clang
support please see the [Clang docs](../../clang/docs/KeyInstructio
@@ -0,0 +1,114 @@
+# Key Instructions debug info in LLVM
+
+Key Instructions reduces the jumpiness of optimized code debug stepping. This
document explains the feature and how it is implemented in LLVM. For Clang
support please see the [Clang docs](../../clang/docs/KeyInstructio
@@ -0,0 +1,114 @@
+# Key Instructions debug info in LLVM
+
+Key Instructions reduces the jumpiness of optimized code debug stepping. This
document explains the feature and how it is implemented in LLVM. For Clang
support please see the [Clang docs](../../clang/docs/KeyInstructio
@@ -0,0 +1,46 @@
+# Key Instructions in Clang
+
+Key Instructions is an LLVM feature that reduces the jumpiness of optimized
code debug stepping. This document explains how Clang applies the necessary
metadata.
+
+## Implementation
+
+See the [LLVM docs](../../llvm/docs/KeyInstr
@@ -63,6 +63,7 @@ intermediate LLVM representation.
ResponseGuide
Remarks
RemoveDIsDebugInfo
+ KeyInstructions
jmorse wrote:
Is there a corresponding table-of-contents for clang too?
https://github.com/llvm/llvm-project/pull/137991
@@ -0,0 +1,114 @@
+# Key Instructions debug info in LLVM
+
+Key Instructions reduces the jumpiness of optimized code debug stepping. This
document explains the feature and how it is implemented in LLVM. For Clang
support please see the [Clang docs](../../clang/docs/KeyInstructio
@@ -0,0 +1,46 @@
+# Key Instructions in Clang
+
+Key Instructions is an LLVM feature that reduces the jumpiness of optimized
code debug stepping. This document explains how Clang applies the necessary
metadata.
+
+## Implementation
+
+See the [LLVM docs](../../llvm/docs/KeyInstr
@@ -0,0 +1,46 @@
+# Key Instructions in Clang
+
+Key Instructions is an LLVM feature that reduces the jumpiness of optimized
code debug stepping. This document explains how Clang applies the necessary
metadata.
+
+## Implementation
+
+See the [LLVM docs](../../llvm/docs/KeyInstr
@@ -0,0 +1,46 @@
+# Key Instructions in Clang
+
+Key Instructions is an LLVM feature that reduces the jumpiness of optimized
code debug stepping. This document explains how Clang applies the necessary
metadata.
+
+## Implementation
+
+See the [LLVM docs](../../llvm/docs/KeyInstr
https://github.com/jmorse commented:
Various recommendations, but looking good.
https://github.com/llvm/llvm-project/pull/137991
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,46 @@
+# Key Instructions in Clang
+
+Key Instructions is an LLVM feature that reduces the jumpiness of optimized
code debug stepping. This document explains how Clang applies the necessary
metadata.
jmorse wrote:
This provides a negative reason (red
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/137991
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse closed
https://github.com/llvm/llvm-project/pull/147551
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse created
https://github.com/llvm/llvm-project/pull/147551
At this time (immediately prior to llvm21 branching) we haven't instrumented
coroutine generation to identify the "key" instructions of things like
co_return and similar. This will lead to worse stepping behavio
https://github.com/jmorse approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/147484
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/144346
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,59 @@
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -gkey-instructions %s
-gno-column-info -debug-info-kind=line-tables-only -emit-llvm -o - \
+// RUN: | FileCheck %s
+
+// g::h and i can be memcpy'd, check the assignment gets Key Instructions
metadata.
+
+struct e {
+
https://github.com/jmorse approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/144346
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse approved this pull request.
LGTM (my least favourite part of github, aside from it not being Phabricator,
is that it chucks away all the inline comments randomly. Yay).
Keeping on the HELP checklines though: if you symlink clang to `/bin/true` then
with no checklines
@@ -1904,7 +1904,8 @@ CGDebugInfo::createInlinedSubprogram(StringRef FuncName,
/*ScopeLine=*/0,
/*Flags=*/llvm::DINode::FlagArtificial,
/*SPFlags=*/llvm::DISubprogram::SPFlagDefinition,
-/*TParams=*/nullptr, /*ThrownTypes=*/nullptr, /*Annotations
https://github.com/jmorse approved this pull request.
LGTM with a question
https://github.com/llvm/llvm-project/pull/145869
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/145869
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -200,12 +200,10 @@
// CHECK-NO-TARGETLIB-SAME: "-L."
// RUN: mkdir -p %t.dir/myroot/target/lib
-// RUN: touch %t.dir/myroot/target/lib/crti.o
// RUN: env SCE_PROSPERO_SDK_DIR=%t.dir/myroot %clang --target=x64_64-sie-ps5
%s -### -Luser 2>&1 | FileCheck --check-prefixes=CHE
https://github.com/jmorse approved this pull request.
No strong opinion on the arguments really, thing can always be re-rationalised
in the future.
> Not sure I follow this question - can you elaborate?
It's a draft fragment of one of the questions I asked that floated to the
bottom, whoops.
@@ -1904,7 +1904,8 @@ CGDebugInfo::createInlinedSubprogram(StringRef FuncName,
/*ScopeLine=*/0,
/*Flags=*/llvm::DINode::FlagArtificial,
/*SPFlags=*/llvm::DISubprogram::SPFlagDefinition,
-/*TParams=*/nullptr, /*ThrownTypes=*/nullptr, /*Annotations
@@ -922,8 +922,8 @@ template <> struct MDNodeKeyImpl {
MDString *LinkageName;
Metadata *File;
unsigned Line;
- Metadata *Type;
unsigned ScopeLine;
+ Metadata *Type;
jmorse wrote:
SGTM
https://github.com/llvm/llvm-project/pull/144107
___
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/144107
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -8,8 +8,14 @@
// HELP-NOT: key-instructions
// KEY-INSTRUCTIONS: "-gkey-instructions"
-// KEY-INSTRUCTIONS: "-mllvm" "-dwarf-use-key-instructions"
// NO-KEY-INSTRUCTIONS-NOT: key-instructions
- TODO: Add smoke test once some functionality has been added.
+// RUN %c
@@ -8,8 +8,14 @@
// HELP-NOT: key-instructions
jmorse wrote:
Not an issue with this patch but, with no positive HELP: prefixes, this check
passes vacuously.
https://github.com/llvm/llvm-project/pull/144115
___
cfe-
@@ -0,0 +1,59 @@
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -gkey-instructions %s
-gno-column-info -debug-info-kind=line-tables-only -emit-llvm -o - \
+// RUN: | FileCheck %s
+
+// g::h and i can be memcpy'd, check the assignment gets Key Instructions
metadata.
+
+struct e {
+
https://github.com/jmorse commented:
>From the context, it feels like clang is going to try turning groups of
>initializers into memcpys, is that right? If so, does that affect the desired
>stepping behaviour, i.e. would multiple assignments be grouped into one
>memcpy? I suppose it's not majo
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/144346
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,162 @@
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -gkey-instructions -x c++
-std=c++17 %s -debug-info-kind=line-tables-only -emit-llvm -o -
-gno-column-info \
+// RUN: | FileCheck %s --implicit-check-not atomGroup --implicit-check-not
atomRank
+// RUN: %clang_cc1 -
@@ -0,0 +1,162 @@
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -gkey-instructions -x c++
-std=c++17 %s -debug-info-kind=line-tables-only -emit-llvm -o -
-gno-column-info \
+// RUN: | FileCheck %s --implicit-check-not atomGroup --implicit-check-not
atomRank
+// RUN: %clang_cc1 -
https://github.com/jmorse approved this pull request.
LGTM, with a test question
https://github.com/llvm/llvm-project/pull/141624
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/141624
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1904,7 +1904,8 @@ CGDebugInfo::createInlinedSubprogram(StringRef FuncName,
/*ScopeLine=*/0,
/*Flags=*/llvm::DINode::FlagArtificial,
/*SPFlags=*/llvm::DISubprogram::SPFlagDefinition,
-/*TParams=*/nullptr, /*ThrownTypes=*/nullptr, /*Annotations
https://github.com/jmorse approved this pull request.
LGTM, I think this raises a few questions about whether we're going to support
non-key-instructions code forever more. AFAIUI the premise is that the
debugging behaviour is worse if you've got groupless instructions in a
key-instructions pr
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/144107
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -922,8 +922,8 @@ template <> struct MDNodeKeyImpl {
MDString *LinkageName;
Metadata *File;
unsigned Line;
- Metadata *Type;
unsigned ScopeLine;
+ Metadata *Type;
jmorse wrote:
This is space packing rather than being related to a functional change
https://github.com/jmorse created
https://github.com/llvm/llvm-project/pull/144383
There are no longer debug-info instructions, thus we don't need this skipping.
Horray!
CC @WenleiHe , `getNextNonDebugInfoInstruction` has a "skip pseudo-probes"
argument that appears to be unused throughout al
https://github.com/jmorse closed
https://github.com/llvm/llvm-project/pull/143207
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jmorse wrote:
Removing the `--experimental-debuginfo-iterators` flag from 1 flang and 1 mlir
test too -- the flag has been a dummy for a month and doesn't do anything, the
extra RUNlines were just extra coverage for when intrinsic support was still
feasible.
https://github.com/llvm/llvm-proje
https://github.com/jmorse updated
https://github.com/llvm/llvm-project/pull/143207
>From b0cf784e2bf0b7c42f5365907dc94353676ae8fc Mon Sep 17 00:00:00 2001
From: Jeremy Morse
Date: Thu, 15 May 2025 14:10:58 +0100
Subject: [PATCH 1/7] [DebugInfo][RemoveDIs] Rip out the UseNewDbgInfoFormat
flag
https://github.com/jmorse updated
https://github.com/llvm/llvm-project/pull/143207
>From b0cf784e2bf0b7c42f5365907dc94353676ae8fc Mon Sep 17 00:00:00 2001
From: Jeremy Morse
Date: Thu, 15 May 2025 14:10:58 +0100
Subject: [PATCH 1/6] [DebugInfo][RemoveDIs] Rip out the UseNewDbgInfoFormat
flag
jmorse wrote:
(Transparency, I wrote some of the code in the PR so dunno if I should review
it,)
> I /think/ function-local types need to go in definitions - in /abstract/
> definitions if they exist (not in the inlined instances or concrete out of
> line instances).
I think this highlights
jmorse wrote:
Interesting -- I suppose the new variable recording where vtables are count as
a source-variable, and in some circumstances the vtable address must be
optimised away? (Whole program devirtualisation for example).
I'd suggest that this isn't a concerning reduction in coverage (bec
https://github.com/jmorse approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/134652
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse approved this pull request.
LGTM with a nit
https://github.com/llvm/llvm-project/pull/134654
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -gkey-instructions
-gno-column-info -x c++ %s -debug-info-kind=line-tables-only -emit-llvm -o - \
+// RUN: | FileCheck %s --implicit-check-not atomGroup --implicit-check-not
atomRank
+
+// RUN: %clang_cc1 -triple x86
@@ -0,0 +1,101 @@
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -gkey-instructions
-gno-column-info -x c++ %s -debug-info-kind=line-tables-only -emit-llvm -o - \
+// RUN: | FileCheck %s --check-prefixes=CHECK,CHECK-CXX
+
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -gkey-instructi
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -gkey-instructions
-gno-column-info -x c++ %s -debug-info-kind=line-tables-only -emit-llvm -o - \
+// RUN: | FileCheck %s --implicit-check-not atomGroup --implicit-check-not
atomRank
+
+// RUN: %clang_cc1 -triple x86_
@@ -1118,6 +1118,8 @@ void CodeGenFunction::EmitBranchThroughCleanup(JumpDest
Dest) {
// Create the branch.
llvm::BranchInst *BI = Builder.CreateBr(Dest.getBlock());
+ // This is the primary instruction for this atom, acting in place of a ret.
jmorse wro
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/134652
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse commented:
If I understand correctly, most of the test changes are to ensure that return
instructions get /an/ atom group, without being specific about which? IMO it'd
be better to make that number explicit to avoid a return accidentally being
part of the _wrong_ atom
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/134654
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse approved this pull request.
Continues to LGTM
https://github.com/llvm/llvm-project/pull/134646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1418,6 +1427,12 @@ void CodeGenFunction::EmitForStmt(const ForStmt &S,
if (CGM.shouldEmitConvergenceTokens())
ConvergenceTokenStack.pop_back();
+
+ if (FinalBodyBB) {
+// Key Instructions: We want the for closing brace to be step-able on to
+// match existin
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/134646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse approved this pull request.
LGTM, with a nit/question inline
https://github.com/llvm/llvm-project/pull/134646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jmorse wrote:
> Performance cost in terms of compilation time?
Compilation time indeed -- there's a small chance that we unexpectedly start
producing masses of useless type information, which would mean we'd have to
rethink this. It'll show up on https://llvm-compile-time-tracker.com/ pretty
https://github.com/jmorse approved this pull request.
> It seems to me that manual finalizeSubprogram() calls were added
> sporadically, not by following declaration-vs-definition logic.
> With the call added [and with #119001], the test output changes: declaration
> DISubprograms have their D
@@ -5055,6 +5055,7 @@ void ItaniumCXXABI::emitBeginCatch(CodeGenFunction &CGF,
// Emit the local.
CodeGenFunction::AutoVarEmission var = CGF.EmitAutoVarAlloca(*CatchParam);
+ ApplyAtomGroup Grp(CGF.getDebugInfo());
InitCatchParam(CGF, *CatchParam, var.getObjectAddress(
https://github.com/jmorse approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/134643
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,51 @@
+// RUN: %clang_cc1 -gkey-instructions -x c++ -std=c++17 %s
-debug-info-kind=line-tables-only -emit-llvm -o - \
+// RUN: | FileCheck %s --implicit-check-not atomGroup --implicit-check-not
atomRank --check-prefixes=CHECK,CHECK-CXX
+
+// RUN: %clang_cc1 -gkey-inst
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/134643
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse approved this pull request.
(LGTM with the braces)
https://github.com/llvm/llvm-project/pull/134641
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/134638
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse approved this pull request.
Much clearer, LGTM thanks!
https://github.com/llvm/llvm-project/pull/134632
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse commented:
I suppose what this is encoding is a (subtle?) assumption about how
definition-subprograms are modelled: they're created once and are immutable.
Wheras declaration-functions can be forwarded declared and then have extra
information added to them when a def
https://github.com/jmorse approved this pull request.
LGTM then, in practice we always get bitten by commandlines + LTO sooner or
later, so I'm confident we'll end up doing-the-right-thing anyway after
breaking our internal CI a few times.
https://github.com/llvm/llvm-project/pull/134627
_
https://github.com/jmorse commented:
On the whole this looks fine to me with a final nit
https://github.com/llvm/llvm-project/pull/130255
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/130255
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1816,6 +1816,15 @@ class CodeGenModule : public CodeGenTypeCache {
void requireVectorDestructorDefinition(const CXXRecordDecl *RD);
bool classNeedsVectorDestructor(const CXXRecordDecl *RD);
+ // Helper to get the alignment for a variable.
+ unsigned getGlobalVarAlign
jmorse wrote:
It sounds like there's agreement that the "before" approach was
better/acceptable, i.e. having a CU-level variable that refers by
`DW_AT_specification` to a variable in the class type. Doing so would also
avoid the customisation for vtable-addresses in the latest patch with the
https://github.com/jmorse closed
https://github.com/llvm/llvm-project/pull/111836
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jmorse wrote:
/me squints -- this was a minor improvement and I've lost all the context
behind it, abandoning as it's not worth revisiting IMO
https://github.com/llvm/llvm-project/pull/111836
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
htt
jmorse wrote:
> To solve this problem in general, it would probably(?) be best to make SROA
> create fragment #dbg_value records if it decomposes an alloca into multiple
> IR values but I have no idea how difficult that would be to accomplish.
An example of this happening today with C++ struct
jmorse wrote:
There's precedent for splitting the debug-info into fragments early, we do
something similar for C++ structured-bindings in SROA and a very similar
process happens when the i128 argument is split up in instruction-selection.
Split-up locations become brittle to optimisations thou
https://github.com/jmorse approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/126967
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse approved this pull request.
LGTM too; thanks for running with this!
https://github.com/llvm/llvm-project/pull/126059
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-c
@@ -1708,19 +1706,9 @@ static void insertDbgValueOrDbgVariableRecord(DIBuilder
&Builder, Value *DV,
static void insertDbgValueOrDbgVariableRecordAfter(
DIBuilder &Builder, Value *DV, DILocalVariable *DIVar, DIExpression
*DIExpr,
-const DebugLoc &NewLoc, BasicBlock::i
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/126059
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse commented:
This looks great, thanks for putting this all together, one nit inline,
Is this intended to be cherry-picked into the release branch or not? Seeing how
the original motivation was to ease downstream compatibilities, I'd assumed
there'd be the need for somet
https://github.com/jmorse approved this pull request.
LGTM on the belief that `-fextend-this-ptr-liveness` hasn't been in the driver
for very long at all -- if that isn't the case, we end up having to ask
questions about supporting it.
https://github.com/llvm/llvm-project/pull/124767
_
https://github.com/jmorse closed
https://github.com/llvm/llvm-project/pull/124288
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 248 matches
Mail list logo
