dwblaikie wrote:
> Looking forward to trying this out!
>
> Should the new flag have some docs and maybe be mentioned in the release
> notes, or do we think it's not ready for prime time yet for some reason?
I'm /pretty/ neutral on that - it's got pretty clear behavior, etc (& in fact
some cla
joker-eph wrote:
Reverted in https://github.com/llvm/llvm-project/pull/93767
(maybe it's just a missing explicit triple in the test?)
https://github.com/llvm/llvm-project/pull/87018
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists
joker-eph wrote:
It also fails on Windows:
https://lab.llvm.org/buildbot/#/builders/271/builds/8095
https://github.com/llvm/llvm-project/pull/87018
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo
dyung wrote:
Hi @dwblaikie the test debug-options.c is failing on the macOS build bot. Can
you take a look?
https://lab.llvm.org/buildbot/#/builders/280/builds/4510
https://github.com/llvm/llvm-project/pull/87018
___
cfe-commits mailing list
cfe-comm
https://github.com/dwblaikie closed
https://github.com/llvm/llvm-project/pull/87018
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
pogo59 wrote:
What @SLTozer said. I don't want "members" to mean "some but not all members"
and "methods" was shorter than "member-functions" (but I'm okay with
"member-functions").
https://github.com/llvm/llvm-project/pull/87018
___
cfe-commits mail
https://github.com/SLTozer approved this pull request.
> Yeah, seems I'm outvoted here. I'm a bit of a pedant for the C++ standard
> language, which doesn't talk about "methods", only "member functions".
All I'd say is that if we went with members, it ought to be
`-gomit-unreferenced-member-fu
https://github.com/SLTozer edited
https://github.com/llvm/llvm-project/pull/87018
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4260,6 +4260,13 @@ defm strict_dwarf : BoolOption<"g", "strict-dwarf",
"the specified version, avoiding features from later versions.">,
NegFlag, BothFlags<[], [ClangOption, CLOption, DXCOption]>>,
Group;
+defm omit_unreferenced_members : BoolOption<"g", "omit
@@ -4260,6 +4260,13 @@ defm strict_dwarf : BoolOption<"g", "strict-dwarf",
"the specified version, avoiding features from later versions.">,
NegFlag, BothFlags<[], [ClangOption, CLOption, DXCOption]>>,
Group;
+defm omit_unreferenced_members : BoolOption<"g", "omit
dwblaikie wrote:
> I think the comment about `s/members/methods/` is still outstanding - I agree
> that methods is more descriptive than members.
Yeah, seems I'm outvoted here. I'm a bit of a pedant for the C++ standard
language, which doesn't talk about "methods", only "member functions". But
@@ -4260,6 +4260,13 @@ defm strict_dwarf : BoolOption<"g", "strict-dwarf",
"the specified version, avoiding features from later versions.">,
NegFlag, BothFlags<[], [ClangOption, CLOption, DXCOption]>>,
Group;
+defm omit_unreferenced_members : BoolOption<"g", "omit
@@ -2755,7 +2755,7 @@ CGDebugInfo::CreateTypeDefinition(const RecordType *Ty) {
// Collect data fields (including static variables and any initializers).
CollectRecordFields(RD, DefUnit, EltTys, FwdDecl);
- if (CXXDecl)
+ if (CXXDecl && !CGM.getCodeGenOpts().DebugOmitUnr
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -debug-info-kind=limited -gomit-unreferenced-members %s
-emit-llvm -o - | FileCheck %s
dwblaikie wrote:
Done
https://github.com/llvm/llvm-project/pull/87018
___
cfe-commits mailing
https://github.com/dwblaikie updated
https://github.com/llvm/llvm-project/pull/87018
>From 6834c245205d1e38a615e97217dada3cd941ed03 Mon Sep 17 00:00:00 2001
From: David Blaikie
Date: Fri, 2 Jun 2023 15:04:14 +
Subject: [PATCH 1/3] [DebugInfo] Add flag to only emit referenced member
functio
@@ -4260,6 +4260,13 @@ defm strict_dwarf : BoolOption<"g", "strict-dwarf",
"the specified version, avoiding features from later versions.">,
NegFlag, BothFlags<[], [ClangOption, CLOption, DXCOption]>>,
Group;
+defm omit_unreferenced_members : BoolOption<"g", "omit
https://github.com/SLTozer commented:
I think the comment about `s/members/methods/` is still outstanding - I agree
that methods is more descriptive than members.
I'm +1 on having this be non-default; adding it to SCE tuning is also not
necessary (or desired) for now, because this is more aggr
@@ -2755,7 +2755,7 @@ CGDebugInfo::CreateTypeDefinition(const RecordType *Ty) {
// Collect data fields (including static variables and any initializers).
CollectRecordFields(RD, DefUnit, EltTys, FwdDecl);
- if (CXXDecl)
+ if (CXXDecl && !CGM.getCodeGenOpts().DebugOmitUnr
https://github.com/SLTozer edited
https://github.com/llvm/llvm-project/pull/87018
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -debug-info-kind=limited -gomit-unreferenced-members %s
-emit-llvm -o - | FileCheck %s
SLTozer wrote:
Test needs renaming for the different flag name?
https://github.com/llvm/llvm-project/pull/87018
_
chrdavis wrote:
Building Chromium with this change shows a decrease of 35% for the PDB TPI
size. The TPI size is capped at 2GB due to a signed int limitation. Since
Chromium to approaching this limitation having this flag would be extremely
beneficial. Can we get this PR completed soon?
ht
adrian-prantl wrote:
Seems to be a reasonable tuning option to have available. I probably wouldn't
want this to be on by default, but I can see the appeal.
https://github.com/llvm/llvm-project/pull/87018
___
cfe-commits mailing list
cfe-commits@lists.
rnk wrote:
To restate the finding, 29% of .debug_info is describing class methods, at
least in Clang.
I think this is a useful mode, and we should land it as is. There are many
users up against the scaling limits of debug info size, and it's helpful to
have this as an option for experimentati
pogo59 wrote:
Thanks for the link back to the Phab review, that was helpful. I didn't offhand
recall the previous round of this. I'll trust the comments I made on that
review. :)
s/members/methods/ in the option name to avoid the incorrect implication of
suppressing data members?
I suggest _
dwblaikie wrote:
Cleaning up some old branches - @pogo59 @rnk who commented on the original
https://reviews.llvm.org/D152017
I think the only outstanding thing was the flag name, I've renamed it from
`-gincomplete-types` to `-gomit-unreferenced-members` to try to address the
feedback. It's no
llvmbot wrote:
@llvm/pr-subscribers-clang-driver
Author: David Blaikie (dwblaikie)
Changes
Complete C++ type information can be quite expensive - and there's
limited value in representing every member function, even those that
can't be called (we don't do similarly for every non-member fun
https://github.com/dwblaikie created
https://github.com/llvm/llvm-project/pull/87018
Complete C++ type information can be quite expensive - and there's
limited value in representing every member function, even those that
can't be called (we don't do similarly for every non-member function
anyway
27 matches
Mail list logo