Page MenuHomePhabricator

alok (Alok Kumar Sharma)
User

Projects

User does not belong to any projects.

User Details

User Since
Oct 13 2019, 9:52 PM (141 w, 4 d)

Recent Activity

Wed, Jun 15

alok updated the diff for D111521: [DebugInfo] Mark OpenMP generated functions as artificial.

Re-based and updated to include one negative testcase.
I could not find a test for VarDecl with DynamicInitKind::NoStub. There are constructors for other DynamicInitKind but not for NoStub. Please help me in case you are aware of the condition when it is produced.

Wed, Jun 15, 1:00 AM · Restricted Project, Restricted Project, debug-info

May 22 2022

alok abandoned D121100: [clang][DebugInfo] clang should not generate DW_TAG_subprogram entry without DW_AT_name.

GNU gdb is now modified to accept functions with linkage name.

May 22 2022, 9:54 PM · Restricted Project, Restricted Project, debug-info

May 10 2022

alok updated the diff for D124982: [clang][OpenMP][DebugInfo] Debug support for variables in containing scope of OMP constructs.

Re-based.

May 10 2022, 2:47 AM · Restricted Project, Restricted Project, Restricted Project, debug-info

May 5 2022

alok updated the diff for D124982: [clang][OpenMP][DebugInfo] Debug support for variables in containing scope of OMP constructs.

re-based.

May 5 2022, 1:22 AM · Restricted Project, Restricted Project, Restricted Project, debug-info

May 4 2022

alok requested review of D124982: [clang][OpenMP][DebugInfo] Debug support for variables in containing scope of OMP constructs.
May 4 2022, 11:08 PM · Restricted Project, Restricted Project, Restricted Project, debug-info

Apr 23 2022

alok committed rGa48300aee570: [clang][OpenMP][DebugInfo] Debug support for TLS variables present in OpenMP… (authored by alok).
[clang][OpenMP][DebugInfo] Debug support for TLS variables present in OpenMP…
Apr 23 2022, 12:00 AM · Restricted Project, Restricted Project
alok closed D123787: [clang][OpenMP][DebugInfo] Debug support for TLS variables when present in OpenMP consructs.
Apr 23 2022, 12:00 AM · Restricted Project, Restricted Project, debug-info

Apr 18 2022

alok updated the diff for D123787: [clang][OpenMP][DebugInfo] Debug support for TLS variables when present in OpenMP consructs.

Re-based.

Apr 18 2022, 5:23 AM · Restricted Project, Restricted Project, debug-info
alok added a comment to D123787: [clang][OpenMP][DebugInfo] Debug support for TLS variables when present in OpenMP consructs.

For an example, if thread local variable is present in copyin clause (testcase attached with the

patch), parameter with same name is generated as parameter to artificial function. When user
inquires the thread Local variable, its debug info is hidden by the parameter. The debug info
for parameters (for thread local) must be suppressed.

What does the dwarfdump output for the old behavior look like? Are the two in the same scope?

Apr 18 2022, 3:05 AM · Restricted Project, Restricted Project, debug-info

Apr 14 2022

alok requested review of D123787: [clang][OpenMP][DebugInfo] Debug support for TLS variables when present in OpenMP consructs.
Apr 14 2022, 5:45 AM · Restricted Project, Restricted Project, debug-info

Mar 28 2022

alok added a comment to D84120: [Debuginfo][SROA] (7/7) Support for DW_OP_implicit_pointer for named and unnamed variables (second strategy)..

This change was brought up in https://github.com/llvm/llvm-project/issues/54290, @alok is this still active? Is there a way we can help to get this patch stack reviewed and landed?

Looks like there was some further discussion here: https://reviews.llvm.org/D84112 and an alluded to llvm-dev thread that might be worth finding.

I believe the corresponding discussion is https://discourse.llvm.org/t/dw-op-implicit-pointer-design-implementation-in-general/53698

It seems like not all the content was transferred over to Discourse, the original thread is https://lists.llvm.org/pipermail/llvm-dev/2019-November/136798.html

Mar 28 2022, 9:47 PM · Restricted Project, debug-info, Restricted Project

Mar 9 2022

alok committed rG94823500a728: [DebugInfo][SROA] Correct debug info for global variables in case of SROA (authored by alok).
[DebugInfo][SROA] Correct debug info for global variables in case of SROA
Mar 9 2022, 11:13 AM · Restricted Project
alok closed D121107: [DebugInfo][SROA] Correct debug info for global variables in case of SROA.
Mar 9 2022, 11:12 AM · Restricted Project, Restricted Project, debug-info
alok updated the diff for D121107: [DebugInfo][SROA] Correct debug info for global variables in case of SROA.

Incorporated comments.

Mar 9 2022, 3:03 AM · Restricted Project, Restricted Project, debug-info
alok added inline comments to D121107: [DebugInfo][SROA] Correct debug info for global variables in case of SROA.
Mar 9 2022, 2:59 AM · Restricted Project, Restricted Project, debug-info
alok updated the diff for D121107: [DebugInfo][SROA] Correct debug info for global variables in case of SROA.

Re-based and updated to incorporate comments.

Mar 9 2022, 2:11 AM · Restricted Project, Restricted Project, debug-info
alok added inline comments to D121107: [DebugInfo][SROA] Correct debug info for global variables in case of SROA.
Mar 9 2022, 2:10 AM · Restricted Project, Restricted Project, debug-info

Mar 8 2022

alok updated the diff for D121107: [DebugInfo][SROA] Correct debug info for global variables in case of SROA.

Re-based and updated to incorporate comments from @aprantl .

Mar 8 2022, 9:55 PM · Restricted Project, Restricted Project, debug-info
alok added inline comments to D121107: [DebugInfo][SROA] Correct debug info for global variables in case of SROA.
Mar 8 2022, 9:04 PM · Restricted Project, Restricted Project, debug-info

Mar 7 2022

alok added a comment to D121107: [DebugInfo][SROA] Correct debug info for global variables in case of SROA.

@alok Thanks for doing this! Can you please add a more descriptive summary of the change?

Mar 7 2022, 9:44 AM · Restricted Project, Restricted Project, debug-info
alok updated the summary of D121107: [DebugInfo][SROA] Correct debug info for global variables in case of SROA.
Mar 7 2022, 9:43 AM · Restricted Project, Restricted Project, debug-info
alok updated the summary of D121107: [DebugInfo][SROA] Correct debug info for global variables in case of SROA.
Mar 7 2022, 9:40 AM · Restricted Project, Restricted Project, debug-info
alok requested review of D121107: [DebugInfo][SROA] Correct debug info for global variables in case of SROA.
Mar 7 2022, 4:22 AM · Restricted Project, Restricted Project, debug-info
alok requested review of D121100: [clang][DebugInfo] clang should not generate DW_TAG_subprogram entry without DW_AT_name.
Mar 7 2022, 2:32 AM · Restricted Project, Restricted Project, debug-info

Dec 22 2021

alok added a comment to D115510: [clang][OpenMP][DebugInfo] Debug support for variables in shared clause of OpenMP task construct.

Thanks @djtodoro .

Dec 22 2021, 6:38 AM · Restricted Project, debug-info
alok committed rG5eb271880c8f: [clang][OpenMP][DebugInfo] Debug support for variables in shared clause of… (authored by alok).
[clang][OpenMP][DebugInfo] Debug support for variables in shared clause of…
Dec 22 2021, 6:36 AM
alok closed D115510: [clang][OpenMP][DebugInfo] Debug support for variables in shared clause of OpenMP task construct.
Dec 22 2021, 6:35 AM · Restricted Project, debug-info

Dec 20 2021

alok added a comment to D115510: [clang][OpenMP][DebugInfo] Debug support for variables in shared clause of OpenMP task construct.

PING !!!

Dec 20 2021, 10:30 PM · Restricted Project, debug-info

Dec 10 2021

alok requested review of D115510: [clang][OpenMP][DebugInfo] Debug support for variables in shared clause of OpenMP task construct.
Dec 10 2021, 4:29 AM · Restricted Project, debug-info

Nov 25 2021

alok committed rG36cb7477d1d4: [clang][OpenMP][DebugInfo] Debug support for private variables inside an OpenMP… (authored by alok).
[clang][OpenMP][DebugInfo] Debug support for private variables inside an OpenMP…
Nov 25 2021, 6:27 AM
alok closed D114504: [clang][DebugInfo] Debug support for private variables inside an OpenMP task construct.
Nov 25 2021, 6:26 AM · Restricted Project, debug-info
alok added a comment to D114504: [clang][DebugInfo] Debug support for private variables inside an OpenMP task construct.

Thanks @djtodoro . I have incorporated all your comments.

Nov 25 2021, 2:24 AM · Restricted Project, debug-info
alok updated the diff for D114504: [clang][DebugInfo] Debug support for private variables inside an OpenMP task construct.

Re-based and incorporated comments from @djtodoro

Nov 25 2021, 2:23 AM · Restricted Project, debug-info
alok added inline comments to D114504: [clang][DebugInfo] Debug support for private variables inside an OpenMP task construct.
Nov 25 2021, 2:22 AM · Restricted Project, debug-info

Nov 24 2021

alok added a comment to D114504: [clang][DebugInfo] Debug support for private variables inside an OpenMP task construct.

Thanks for doing this! Can you please update the summary, since it hard to read with the format like this (at least, just try to reformat the debugger output properly with the Phabricator formatters)?

Nov 24 2021, 7:01 AM · Restricted Project, debug-info
alok updated the summary of D114504: [clang][DebugInfo] Debug support for private variables inside an OpenMP task construct.
Nov 24 2021, 7:01 AM · Restricted Project, debug-info

Nov 23 2021

alok added reviewers for D114504: [clang][DebugInfo] Debug support for private variables inside an OpenMP task construct: jini.susan, jini.susan.george.
Nov 23 2021, 10:59 PM · Restricted Project, debug-info
alok requested review of D114504: [clang][DebugInfo] Debug support for private variables inside an OpenMP task construct.
Nov 23 2021, 10:59 PM · Restricted Project, debug-info

Oct 10 2021

alok requested review of D111521: [DebugInfo] Mark OpenMP generated functions as artificial.
Oct 10 2021, 11:03 PM · Restricted Project, Restricted Project, debug-info

Sep 23 2021

alok abandoned D109590: [NFCI] Rename functions LLVMDIBuilder* to llvmDIBuilder*.
Sep 23 2021, 11:55 PM · Restricted Project, debug-info

Sep 17 2021

alok updated the diff for D109597: [DebugInfo] Fix of crash due to DwarfUnit::getOrCreateContextDIE returning NULL.

Minor testcase update.

Sep 17 2021, 1:18 AM · Restricted Project, debug-info

Sep 16 2021

alok updated the diff for D109597: [DebugInfo] Fix of crash due to DwarfUnit::getOrCreateContextDIE returning NULL.

Included comments from @dblaikie

Sep 16 2021, 11:35 PM · Restricted Project, debug-info

Sep 15 2021

alok committed rGa5b72abc9eaa: [DebugInfo] Enhance DIImportedEntity to accept children entities (authored by alok).
[DebugInfo] Enhance DIImportedEntity to accept children entities
Sep 15 2021, 10:37 PM
alok closed D109343: [DebugInfo] Enhance DIImportedEntity to accept children entities for renamed variables.
Sep 15 2021, 10:36 PM · Restricted Project, debug-info
alok added a comment to D109343: [DebugInfo] Enhance DIImportedEntity to accept children entities for renamed variables.

Generally looks OK to me.

Sep 15 2021, 10:01 PM · Restricted Project, debug-info

Sep 14 2021

alok updated the diff for D109343: [DebugInfo] Enhance DIImportedEntity to accept children entities for renamed variables.

Re-based.

Sep 14 2021, 10:42 PM · Restricted Project, debug-info
alok added a reviewer for D109343: [DebugInfo] Enhance DIImportedEntity to accept children entities for renamed variables: dblaikie.
Sep 14 2021, 9:51 PM · Restricted Project, debug-info
alok updated the summary of D109343: [DebugInfo] Enhance DIImportedEntity to accept children entities for renamed variables.
Sep 14 2021, 9:51 PM · Restricted Project, debug-info
alok added a comment to D109343: [DebugInfo] Enhance DIImportedEntity to accept children entities for renamed variables.

The subject might be slightly misleading - DIImportedEntity already supports importing variables (see C++ like this:

namespace ns {
extern int i;
int i;
}
namespace ns2 {
using ns::i;
}
int main() {
  return ns2::i;
}

which produces a DW_TAG_imported_declaration in DW_TAG_namespace ns2 that imports the DW_TAG_variable i from DW_TAG_namespace ns.

. This patch is specifically about supporting a single imported entity declaration importing multiple entities at the same time, but not a whole namespace of them?

Hmm, nope - it looks like it's only testing importing a single variable. What sort of DWARF are you expecting to generate when importing multiple variables (when "children" has a size greater than 1). Oh, in the implementation in DwarfDebug it's still generating separate DW_TAG_imported_declaration for each thing - so why not encode these as separate DIImportedDeclarations, which would already be supported in the current IR handling, so far as I can tell?

Sep 14 2021, 3:57 AM · Restricted Project, debug-info

Sep 12 2021

alok updated the summary of D109343: [DebugInfo] Enhance DIImportedEntity to accept children entities for renamed variables.
Sep 12 2021, 9:39 PM · Restricted Project, debug-info

Sep 10 2021

alok added a comment to D109590: [NFCI] Rename functions LLVMDIBuilder* to llvmDIBuilder*.

The LLVM C API is a stable FFI API. It's not possible to change any function names.

Sep 10 2021, 6:48 AM · Restricted Project, debug-info
alok added a comment to D109597: [DebugInfo] Fix of crash due to DwarfUnit::getOrCreateContextDIE returning NULL.

is this related to flang only?

Sep 10 2021, 6:29 AM · Restricted Project, debug-info
alok updated the summary of D109597: [DebugInfo] Fix of crash due to DwarfUnit::getOrCreateContextDIE returning NULL.
Sep 10 2021, 5:07 AM · Restricted Project, debug-info
alok requested review of D109597: [DebugInfo] Fix of crash due to DwarfUnit::getOrCreateContextDIE returning NULL.
Sep 10 2021, 5:06 AM · Restricted Project, debug-info
alok added a comment to D109590: [NFCI] Rename functions LLVMDIBuilder* to llvmDIBuilder*.

The rest of the C API uses an "LLVM" prefix. Does it really make sense to use a different one for the DIBuilder functions?

Sep 10 2021, 3:42 AM · Restricted Project, debug-info
alok updated the diff for D109343: [DebugInfo] Enhance DIImportedEntity to accept children entities for renamed variables.

Updated to satisfy clang-tidy for new code.

Sep 10 2021, 3:24 AM · Restricted Project, debug-info
alok requested review of D109590: [NFCI] Rename functions LLVMDIBuilder* to llvmDIBuilder*.
Sep 10 2021, 3:16 AM · Restricted Project, debug-info

Sep 7 2021

alok updated the diff for D109343: [DebugInfo] Enhance DIImportedEntity to accept children entities for renamed variables.

Re-based and added backward comp test.

Sep 7 2021, 12:07 AM · Restricted Project, debug-info

Sep 6 2021

alok requested review of D109343: [DebugInfo] Enhance DIImportedEntity to accept children entities for renamed variables.
Sep 6 2021, 11:14 PM · Restricted Project, debug-info

May 13 2021

alok added a comment to D99160: [X86][FastISEL] Support DW_TAG_call_site_parameter with FastISEL.

I think that the Debug Entry Values feature should not be enabled by default for non optimized code, so the TargetOptions::ShouldEmitDebugEntryValues() should be patched with checking of optimization level (it should be > 0).

That's currently intended to be already handled by the frontend, right? (clang only sets EnableDebugEntryValues (which ShouldEmitDebugEntryValues checks (hmm, it checks under 'or', not 'and', so I'm not sure where the "only above -O0" is implemented, but it is implemented somewhere?) if optimizations are enabled, yeah?)

Oh, is entry_values actually not conditionalized? It's only the call_site support that's currently conditionalized on "above -O0"?

Looks like there is no explicit check of optimization level (above "-O0"), neither on frontend nor backend for entry-values generation. I think it is the situation since there should not be any optimization (at least that I am aware of, in the case of C/C++) that would cause the entry-values generation...

Hmm - If that's the case, and we currently have some cases where entry_values are emitted at -O0, I'm not sure /not/ emitting those is the right call either. If we believe/have data to show that there are so few useful uses of entry_value at -O0 that it's not worth the DWARF size growth to put call_sites in at -O0, then I think it might still be worth leaving the entry_values in (unless they take up a bunch of extra space) for the cases of mixed optimization compilation (-O0 some code you're debugging, but building the rest with optimizations).

Yeah... That is valuable example... I am thinking in that direction as well, and I am closer to the enabling it for -O0 case if that is useful (and there is no dramatic cost in terms of DWARF size).

Does anyone have this example (where DW_OP_entry_value is used at -O0)? It'd be great to look at it & see if it's a case of unnecessarily losing the location, or legitimately losing it and using entry_value for best-effort recovery (& then a question of whether the loss is appropriate at -O0, or if we want to pessimize -O0 further to avoid the loss).

I think this ^ still needs understanding/investigation. Do you have an example with OP_entry_value at -O0?

I'd worry about turning on call_sites at -O0 - there'd be a lot more calls (especially for C++ code with lots of implicit operations), but numbers will be needed in any case, so not worth much speculation.

Sorry for late response.
I tried building https://github.com/flang-compiler/classic-flang-llvm-project.git (branch release_11x) with compiler (current patch (https://reviews.llvm.org/D99160) and https://reviews.llvm.org/D99238) with -O0 -g .
Interestingly there was no difference.
Reason: https://reviews.llvm.org/D99238 is not sufficient for clang/clang++ to enable call-site generation with FastISel though it is sufficient for Flang compiler.
Below additional patch is needed to generate call-sites

`````````````````````````````````````

diff --git a/clang/lib/CodeGen/CGDebugInfo.cpp b/clang/lib/CodeGen/CGDebugInfo.cpp
index a77f52bd235b..8d4e11faa018 100644

  • a/clang/lib/CodeGen/CGDebugInfo.cpp

+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -5149,9 +5149,9 @@ llvm::DebugLoc CGDebugInfo::SourceLocToDebugLoc(SourceLocation Loc) {
}

llvm::DINode::DIFlags CGDebugInfo::getCallSiteRelatedAttrs() const {

  • // Call site-related attributes are only useful in optimized programs, and
  • // when there's a possibility of debugging backtraces.
  • if (!CGM.getLangOpts().Optimize || DebugKind == codegenoptions::NoDebugInfo ||

+ Call site-related attributes are useful when there's a possibility of
+
debugging backtraces.
+ if (DebugKind == codegenoptions::NoDebugInfo ||

  DebugKind == codegenoptions::LocTrackingOnly)
return llvm::DINode::FlagZero;
`````````````````````````````````````

With this patch Clang/Clang++ turn on LLVM IR flag "DIFlagAllCallsDescribed", in absence of this LLVM does not generate call-site.

With the above patch applied below is the comparison of sizes of shared libraries.

Name of shared library - Size (without callsite) - Size (with callsites) - % incresase in size

```````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````

PipSqueak.so 73192 75048 2%
SecondLib.so 73192 75048 2%
TestPlugin.so 1694024 1700704 0%
libLLVMDlltoolDriver.so 336568 347872 3%
libLLVMDebugInfoPDB.so 14463832 15360784 6%
libLLVMOrcError.so 108880 111184 2%
libLLVMTarget.so 2645104 2677448 1%
libLLVMFrontendOpenMP.so 2354728 2505232 6%
libLLVMProfileData.so 7901688 8373632 5%
libLLVMOrcJIT.so 28838432 30490640 5%
libLLVMRemarks.so 3311680 3551856 7%
libgtest.so 2374120 2523112 6%
libLLVMDemangle.so 1350616 1490832 10%
libLLVMAsmParser.so 6961216 7366040 5%
LLVMHello.so 394624 396120 0%
libLLVMGlobalISel.so 18886648 19698008 4%
libLLVMDebugInfoMSF.so 1288376 1365040 5%
libLLVMCoverage.so 4225224 4502104 6%
libLLVMFuzzMutate.so 3859968 3973808 2%
libRemarks.so 6696 6696 0%
libLLVMDebugInfoDWARF.so 11914848 12750784 7%
libLLVMMCParser.so 6419464 6873000 7%
libLLVMTableGen.so 4855536 5180760 6%
libLLVMDWARFLinker.so 5407528 5628576 4%
Bye.so 1858848 1872672 0%
libLLVMMCJIT.so 1470952 1526544 3%
libLLVMMC.so 16931504 17741376 4%
libLLVMipo.so 43554712 46019392 5%
libLLVMLineEditor.so 208216 216360 3%
libbenchmark_main.so 18904 19408 2%
libbenchmark.so 3308304 3507632 6%
libLTO.so 2240720 2277408 1%
libLLVMInterpreter.so 2614696 2749128 5%
libLLVMTransformUtils.so 47925248 50476512 5%
libLLVMX86Desc.so 8047928 8213152 2%
libLLVMCoroutines.so 6478080 6766880 4%
libLLVMJITLink.so 5590936 6066736 8%
libLLVMVectorize.so 19557808 20665544 5%
libLLVMX86Disassembler.so 2820056 2849376 1%
libLLVMBitReader.so 8282648 8823240 6%
libLLVMMCA.so 3242016 3405624 5%
libLLVMBitWriter.so 6544032 6867976 4%
libLLVMMIRParser.so 5739688 5980104 4%
libLLVMLTO.so 13272272 13786192 3%
libLLVMCore.so 46109224 48840008 5%
libLLVMBitstreamReader.so 561896 600624 6%
libLLVMObjectYAML.so 23110160 24648160 6%
libLLVMSupport.so 20349728 21953112 7%
libLLVMIRReader.so 1215672 1237960 1%
libLLVMX86Info.so 76488 76624 0%
libLLVMSelectionDAG.so 34358968 36876128 7%
libLLVMExecutionEngine.so 2962160 3073224 3%
libLLVMSymbolize.so 1980760 2089728 5%
libLLVMPasses.so 18574960 19459712 4%
libLLVMOption.so 869784 920976 5%
libLLVMObject.so 15138656 16383168 8%
libLLVMTextAPI.so 3191272 3384560 6%
libLLVMX86CodeGen.so 55202744 58068088 5%
libLLVMAggressiveInstCombine.so 2354936 2419048 2%
libLLVMExtensions.so 23904 23904 0%
libLLVMWindowsManifest.so 351608 370168 5%
libLLVMObjCARCOpts.so 4964488 5150120 3%
libLLVMBinaryFormat.so 1325752 1431448 7%
libLLVMDebugInfoGSYM.so 2909272 3094616 6%
libLLVMTestingSupport.so 623608 656640 5%
libgtest_main.so 42856 43608 1%
libLLVMLinker.so 3070264 3210248 4%
libLLVMCFGuard.so 1082488 1096104 1%
libLLVMCodeGen.so 139859816 146452160 4%
libLLVMDebugInfoCodeView.so 7742896 8497704 9%
libLLVMX86AsmParser.so 2590816 2714008 4%
libLLVMRuntimeDyld.so 6592016 7094048 7%
libLLVMInstCombine.so 18194728 19705184 8%
BugpointPasses.so 780112 788304 1%
libLLVMScalarOpts.so 73110536 77534912 6%
libLLVMXRay.so 3993696 4251280 6%
libLLVMMCDisassembler.so 1292912 1313536 1%
libLLVMFrontendOpenACC.so 96008 102656 6%
libLLVMInstrumentation.so 21038808 22351384 6%
libLLVMLibDriver.so 1595936 1638704 2%
libLLVMAsmPrinter.so 25818000 26842816 3%
libLLVMAnalysis.so 79615056 83995856 5%

`````````````````````````````````````````````````````````````````````

sum 79615057 83995857 5%

So the conclusion is,

  • We have a Flag which can help us if we want to enable callsite generation selectively (only for Flang)

It doesn't seem to me, so far, like this is a place where Flang and Clang should diverge - they're both doing the same sort of thing for the same reasons/likely with the same sort of tradeoffs of location accuracy V size cost.

  • If we are fine with 5% increase in size, we can enable call-site generation by default.

I'd actually be somewhat more worried about object size, rather than/in addition to executable size, due to the increase in relocations (especially with DWARFv5 (& especially with the -mllvm -minimize-addr-in-v5=Ranges which further reduces debug_addr, but can't handle labels and call sites (unlike -minimize-addr-in-v5=Expressions or -minimize-addr-in-v5=Form)), which does a lot to reduce the number of relocations by using debug_addr and address sharing on debug_rnglists/loclists/etc) which can't be compressed, etc.

Below is the comparison of total size of object files (*.o) for same build (default (O0) + -g).

sum 3535044960 3680496672 4%

I shall come back with numbers for options O0 -gdwarf-5 -mllvm -minimize-addr-in-v5=Ranges .

May 13 2021, 1:00 AM · Restricted Project, Restricted Project, debug-info

Apr 26 2021

alok added a comment to D101255: [DebugInfo][llvm-dwarfdump] Fix dumping of unit header with DW_UT_partial type.

LGTM. Not sure how we missed partial units the first time around--thanks!

Apr 26 2021, 10:11 PM · Restricted Project, debug-info
alok committed rG5a26345fe225: [DebugInfo][llvm-dwarfdump] Fix printing of Unit header with DW_UT_partial type (authored by alok).
[DebugInfo][llvm-dwarfdump] Fix printing of Unit header with DW_UT_partial type
Apr 26 2021, 10:05 PM
alok closed D101255: [DebugInfo][llvm-dwarfdump] Fix dumping of unit header with DW_UT_partial type.
Apr 26 2021, 10:05 PM · Restricted Project, debug-info

Apr 25 2021

alok updated the diff for D101255: [DebugInfo][llvm-dwarfdump] Fix dumping of unit header with DW_UT_partial type.

Updated to do minor correction in comment of test case.

Apr 25 2021, 10:08 PM · Restricted Project, debug-info
alok requested review of D101255: [DebugInfo][llvm-dwarfdump] Fix dumping of unit header with DW_UT_partial type.
Apr 25 2021, 7:51 AM · Restricted Project, debug-info

Apr 19 2021

alok added a comment to D99160: [X86][FastISEL] Support DW_TAG_call_site_parameter with FastISEL.

I think that the Debug Entry Values feature should not be enabled by default for non optimized code, so the TargetOptions::ShouldEmitDebugEntryValues() should be patched with checking of optimization level (it should be > 0).

That's currently intended to be already handled by the frontend, right? (clang only sets EnableDebugEntryValues (which ShouldEmitDebugEntryValues checks (hmm, it checks under 'or', not 'and', so I'm not sure where the "only above -O0" is implemented, but it is implemented somewhere?) if optimizations are enabled, yeah?)

Oh, is entry_values actually not conditionalized? It's only the call_site support that's currently conditionalized on "above -O0"?

Looks like there is no explicit check of optimization level (above "-O0"), neither on frontend nor backend for entry-values generation. I think it is the situation since there should not be any optimization (at least that I am aware of, in the case of C/C++) that would cause the entry-values generation...

Hmm - If that's the case, and we currently have some cases where entry_values are emitted at -O0, I'm not sure /not/ emitting those is the right call either. If we believe/have data to show that there are so few useful uses of entry_value at -O0 that it's not worth the DWARF size growth to put call_sites in at -O0, then I think it might still be worth leaving the entry_values in (unless they take up a bunch of extra space) for the cases of mixed optimization compilation (-O0 some code you're debugging, but building the rest with optimizations).

Yeah... That is valuable example... I am thinking in that direction as well, and I am closer to the enabling it for -O0 case if that is useful (and there is no dramatic cost in terms of DWARF size).

Does anyone have this example (where DW_OP_entry_value is used at -O0)? It'd be great to look at it & see if it's a case of unnecessarily losing the location, or legitimately losing it and using entry_value for best-effort recovery (& then a question of whether the loss is appropriate at -O0, or if we want to pessimize -O0 further to avoid the loss).

I think this ^ still needs understanding/investigation. Do you have an example with OP_entry_value at -O0?

I'd worry about turning on call_sites at -O0 - there'd be a lot more calls (especially for C++ code with lots of implicit operations), but numbers will be needed in any case, so not worth much speculation.

Sorry for late response.
I tried building https://github.com/flang-compiler/classic-flang-llvm-project.git (branch release_11x) with compiler (current patch (https://reviews.llvm.org/D99160) and https://reviews.llvm.org/D99238) with -O0 -g .
Interestingly there was no difference.
Reason: https://reviews.llvm.org/D99238 is not sufficient for clang/clang++ to enable call-site generation with FastISel though it is sufficient for Flang compiler.
Below additional patch is needed to generate call-sites

`````````````````````````````````````

diff --git a/clang/lib/CodeGen/CGDebugInfo.cpp b/clang/lib/CodeGen/CGDebugInfo.cpp
index a77f52bd235b..8d4e11faa018 100644

  • a/clang/lib/CodeGen/CGDebugInfo.cpp

+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -5149,9 +5149,9 @@ llvm::DebugLoc CGDebugInfo::SourceLocToDebugLoc(SourceLocation Loc) {
}

llvm::DINode::DIFlags CGDebugInfo::getCallSiteRelatedAttrs() const {

  • // Call site-related attributes are only useful in optimized programs, and
  • // when there's a possibility of debugging backtraces.
  • if (!CGM.getLangOpts().Optimize || DebugKind == codegenoptions::NoDebugInfo ||

+ Call site-related attributes are useful when there's a possibility of
+
debugging backtraces.
+ if (DebugKind == codegenoptions::NoDebugInfo ||

  DebugKind == codegenoptions::LocTrackingOnly)
return llvm::DINode::FlagZero;
`````````````````````````````````````

With this patch Clang/Clang++ turn on LLVM IR flag "DIFlagAllCallsDescribed", in absence of this LLVM does not generate call-site.

With the above patch applied below is the comparison of sizes of shared libraries.

Name of shared library - Size (without callsite) - Size (with callsites) - % incresase in size

```````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````

PipSqueak.so 73192 75048 2%
SecondLib.so 73192 75048 2%
TestPlugin.so 1694024 1700704 0%
libLLVMDlltoolDriver.so 336568 347872 3%
libLLVMDebugInfoPDB.so 14463832 15360784 6%
libLLVMOrcError.so 108880 111184 2%
libLLVMTarget.so 2645104 2677448 1%
libLLVMFrontendOpenMP.so 2354728 2505232 6%
libLLVMProfileData.so 7901688 8373632 5%
libLLVMOrcJIT.so 28838432 30490640 5%
libLLVMRemarks.so 3311680 3551856 7%
libgtest.so 2374120 2523112 6%
libLLVMDemangle.so 1350616 1490832 10%
libLLVMAsmParser.so 6961216 7366040 5%
LLVMHello.so 394624 396120 0%
libLLVMGlobalISel.so 18886648 19698008 4%
libLLVMDebugInfoMSF.so 1288376 1365040 5%
libLLVMCoverage.so 4225224 4502104 6%
libLLVMFuzzMutate.so 3859968 3973808 2%
libRemarks.so 6696 6696 0%
libLLVMDebugInfoDWARF.so 11914848 12750784 7%
libLLVMMCParser.so 6419464 6873000 7%
libLLVMTableGen.so 4855536 5180760 6%
libLLVMDWARFLinker.so 5407528 5628576 4%
Bye.so 1858848 1872672 0%
libLLVMMCJIT.so 1470952 1526544 3%
libLLVMMC.so 16931504 17741376 4%
libLLVMipo.so 43554712 46019392 5%
libLLVMLineEditor.so 208216 216360 3%
libbenchmark_main.so 18904 19408 2%
libbenchmark.so 3308304 3507632 6%
libLTO.so 2240720 2277408 1%
libLLVMInterpreter.so 2614696 2749128 5%
libLLVMTransformUtils.so 47925248 50476512 5%
libLLVMX86Desc.so 8047928 8213152 2%
libLLVMCoroutines.so 6478080 6766880 4%
libLLVMJITLink.so 5590936 6066736 8%
libLLVMVectorize.so 19557808 20665544 5%
libLLVMX86Disassembler.so 2820056 2849376 1%
libLLVMBitReader.so 8282648 8823240 6%
libLLVMMCA.so 3242016 3405624 5%
libLLVMBitWriter.so 6544032 6867976 4%
libLLVMMIRParser.so 5739688 5980104 4%
libLLVMLTO.so 13272272 13786192 3%
libLLVMCore.so 46109224 48840008 5%
libLLVMBitstreamReader.so 561896 600624 6%
libLLVMObjectYAML.so 23110160 24648160 6%
libLLVMSupport.so 20349728 21953112 7%
libLLVMIRReader.so 1215672 1237960 1%
libLLVMX86Info.so 76488 76624 0%
libLLVMSelectionDAG.so 34358968 36876128 7%
libLLVMExecutionEngine.so 2962160 3073224 3%
libLLVMSymbolize.so 1980760 2089728 5%
libLLVMPasses.so 18574960 19459712 4%
libLLVMOption.so 869784 920976 5%
libLLVMObject.so 15138656 16383168 8%
libLLVMTextAPI.so 3191272 3384560 6%
libLLVMX86CodeGen.so 55202744 58068088 5%
libLLVMAggressiveInstCombine.so 2354936 2419048 2%
libLLVMExtensions.so 23904 23904 0%
libLLVMWindowsManifest.so 351608 370168 5%
libLLVMObjCARCOpts.so 4964488 5150120 3%
libLLVMBinaryFormat.so 1325752 1431448 7%
libLLVMDebugInfoGSYM.so 2909272 3094616 6%
libLLVMTestingSupport.so 623608 656640 5%
libgtest_main.so 42856 43608 1%
libLLVMLinker.so 3070264 3210248 4%
libLLVMCFGuard.so 1082488 1096104 1%
libLLVMCodeGen.so 139859816 146452160 4%
libLLVMDebugInfoCodeView.so 7742896 8497704 9%
libLLVMX86AsmParser.so 2590816 2714008 4%
libLLVMRuntimeDyld.so 6592016 7094048 7%
libLLVMInstCombine.so 18194728 19705184 8%
BugpointPasses.so 780112 788304 1%
libLLVMScalarOpts.so 73110536 77534912 6%
libLLVMXRay.so 3993696 4251280 6%
libLLVMMCDisassembler.so 1292912 1313536 1%
libLLVMFrontendOpenACC.so 96008 102656 6%
libLLVMInstrumentation.so 21038808 22351384 6%
libLLVMLibDriver.so 1595936 1638704 2%
libLLVMAsmPrinter.so 25818000 26842816 3%
libLLVMAnalysis.so 79615056 83995856 5%

`````````````````````````````````````````````````````````````````````

sum 79615057 83995857 5%

So the conclusion is,

  • We have a Flag which can help us if we want to enable callsite generation selectively (only for Flang)

It doesn't seem to me, so far, like this is a place where Flang and Clang should diverge - they're both doing the same sort of thing for the same reasons/likely with the same sort of tradeoffs of location accuracy V size cost.

  • If we are fine with 5% increase in size, we can enable call-site generation by default.

I'd actually be somewhat more worried about object size, rather than/in addition to executable size, due to the increase in relocations (especially with DWARFv5 (& especially with the -mllvm -minimize-addr-in-v5=Ranges which further reduces debug_addr, but can't handle labels and call sites (unlike -minimize-addr-in-v5=Expressions or -minimize-addr-in-v5=Form)), which does a lot to reduce the number of relocations by using debug_addr and address sharing on debug_rnglists/loclists/etc) which can't be compressed, etc.

Apr 19 2021, 9:25 PM · Restricted Project, Restricted Project, debug-info
alok added a comment to D99160: [X86][FastISEL] Support DW_TAG_call_site_parameter with FastISEL.

I think that the Debug Entry Values feature should not be enabled by default for non optimized code, so the TargetOptions::ShouldEmitDebugEntryValues() should be patched with checking of optimization level (it should be > 0).

That's currently intended to be already handled by the frontend, right? (clang only sets EnableDebugEntryValues (which ShouldEmitDebugEntryValues checks (hmm, it checks under 'or', not 'and', so I'm not sure where the "only above -O0" is implemented, but it is implemented somewhere?) if optimizations are enabled, yeah?)

Oh, is entry_values actually not conditionalized? It's only the call_site support that's currently conditionalized on "above -O0"?

Looks like there is no explicit check of optimization level (above "-O0"), neither on frontend nor backend for entry-values generation. I think it is the situation since there should not be any optimization (at least that I am aware of, in the case of C/C++) that would cause the entry-values generation...

Hmm - If that's the case, and we currently have some cases where entry_values are emitted at -O0, I'm not sure /not/ emitting those is the right call either. If we believe/have data to show that there are so few useful uses of entry_value at -O0 that it's not worth the DWARF size growth to put call_sites in at -O0, then I think it might still be worth leaving the entry_values in (unless they take up a bunch of extra space) for the cases of mixed optimization compilation (-O0 some code you're debugging, but building the rest with optimizations).

Yeah... That is valuable example... I am thinking in that direction as well, and I am closer to the enabling it for -O0 case if that is useful (and there is no dramatic cost in terms of DWARF size).

Does anyone have this example (where DW_OP_entry_value is used at -O0)? It'd be great to look at it & see if it's a case of unnecessarily losing the location, or legitimately losing it and using entry_value for best-effort recovery (& then a question of whether the loss is appropriate at -O0, or if we want to pessimize -O0 further to avoid the loss).

I'd worry about turning on call_sites at -O0 - there'd be a lot more calls (especially for C++ code with lots of implicit operations), but numbers will be needed in any case, so not worth much speculation.

Apr 19 2021, 10:01 AM · Restricted Project, Restricted Project, debug-info

Apr 2 2021

alok added inline comments to D99238: [DebugInfo] Enable the call site parameter feature by default.
Apr 2 2021, 11:20 AM · Restricted Project, Restricted Project, debug-info
alok added a reviewer for D99160: [X86][FastISEL] Support DW_TAG_call_site_parameter with FastISEL: dblaikie.
Apr 2 2021, 10:58 AM · Restricted Project, Restricted Project, debug-info
alok added inline comments to D99238: [DebugInfo] Enable the call site parameter feature by default.
Apr 2 2021, 10:57 AM · Restricted Project, Restricted Project, debug-info
alok added a comment to D99160: [X86][FastISEL] Support DW_TAG_call_site_parameter with FastISEL.

FastISel is normally used only at -O0, I wouldn't expect any parameters to be optimized out at -O0.
The test is running llc with default optimization, which is -O2, and forcing fast-isel; this is not a usual combination and I wouldn't expect us to spend any effort making sure debug info works well with that combination.

If flang is forcing fast-isel even with optimization, that sounds like a problem for flang to solve, not LLVM.

Thanks for your comments. I am sorry as the earlier used options in test case were more confusing than helpful. I have changed that now.
The updated testcase at "-O0" with FastISel does have optimized out parameter, this is because generation of "DW_OP_GNU_entry_value" is enabled starting from "-O0". This causes llvm to generate it whenever it gets opportunity (more local variables to preserve may be the reason).
The concern here is only DW_OP_GNU_entry_value is not sufficient and should be supported with "DW_TAG_GNU_call_site_parameter", which I tried in current patch.

"DW_OP_GNU_entry_value" is enabled starting from "-O0".

I am wondering if this is true...

Apr 2 2021, 4:29 AM · Restricted Project, Restricted Project, debug-info
alok added a reviewer for D99160: [X86][FastISEL] Support DW_TAG_call_site_parameter with FastISEL: probinson.
Apr 2 2021, 4:19 AM · Restricted Project, Restricted Project, debug-info
alok added a comment to D99160: [X86][FastISEL] Support DW_TAG_call_site_parameter with FastISEL.

FastISel is normally used only at -O0, I wouldn't expect any parameters to be optimized out at -O0.
The test is running llc with default optimization, which is -O2, and forcing fast-isel; this is not a usual combination and I wouldn't expect us to spend any effort making sure debug info works well with that combination.

If flang is forcing fast-isel even with optimization, that sounds like a problem for flang to solve, not LLVM.

Apr 2 2021, 3:16 AM · Restricted Project, Restricted Project, debug-info
alok updated the diff for D99160: [X86][FastISEL] Support DW_TAG_call_site_parameter with FastISEL.

Updated testcase to use option "-O0", earlier default option was being used instead.

Apr 2 2021, 3:07 AM · Restricted Project, Restricted Project, debug-info

Apr 1 2021

alok updated the diff for D99238: [DebugInfo] Enable the call site parameter feature by default.

Updated to address comments from @djtodoro

Apr 1 2021, 3:53 AM · Restricted Project, Restricted Project, debug-info
alok added inline comments to D99238: [DebugInfo] Enable the call site parameter feature by default.
Apr 1 2021, 3:46 AM · Restricted Project, Restricted Project, debug-info
alok updated the diff for D99160: [X86][FastISEL] Support DW_TAG_call_site_parameter with FastISEL.

Re-based and minor changes.

Apr 1 2021, 3:27 AM · Restricted Project, Restricted Project, debug-info
alok added a comment to D99709: [DebugInfo] Avoid generating DW_TAG_GNU_call_site if no DW_TAG_GNU_call_site_parameter present.

Actually, the call_site DIE is being used for printing artificial frames for tail calls...

Apr 1 2021, 2:31 AM · Restricted Project, debug-info
alok requested review of D99709: [DebugInfo] Avoid generating DW_TAG_GNU_call_site if no DW_TAG_GNU_call_site_parameter present.
Apr 1 2021, 2:13 AM · Restricted Project, debug-info

Mar 29 2021

alok committed rG9fb0025f7084: [DebugInfo] Upgrade DISubragne::count to accept DIExpression also (authored by alok).
[DebugInfo] Upgrade DISubragne::count to accept DIExpression also
Mar 29 2021, 9:30 PM
alok closed D99335: [DebugInfo] Upgrade DISubragne::count to accept DIExpression also.
Mar 29 2021, 9:30 PM · Restricted Project, debug-info
alok added a comment to D99335: [DebugInfo] Upgrade DISubragne::count to accept DIExpression also.

Thanks, I think this makes sense!

Mar 29 2021, 9:28 PM · Restricted Project, debug-info

Mar 25 2021

alok requested review of D99335: [DebugInfo] Upgrade DISubragne::count to accept DIExpression also.
Mar 25 2021, 6:25 AM · Restricted Project, debug-info

Mar 23 2021

alok updated the diff for D99238: [DebugInfo] Enable the call site parameter feature by default.

Re-based after setting the parent patch.

Mar 23 2021, 10:38 PM · Restricted Project, Restricted Project, debug-info
alok requested review of D99238: [DebugInfo] Enable the call site parameter feature by default.
Mar 23 2021, 10:25 PM · Restricted Project, Restricted Project, debug-info
alok updated the diff for D99160: [X86][FastISEL] Support DW_TAG_call_site_parameter with FastISEL.

Updated to incorporate comments from @djtodoro

  • to split out separate patch for clang change.

and fixed clang-format issue.

Mar 23 2021, 10:20 PM · Restricted Project, Restricted Project, debug-info
alok updated the summary of D99160: [X86][FastISEL] Support DW_TAG_call_site_parameter with FastISEL.
Mar 23 2021, 10:17 PM · Restricted Project, Restricted Project, debug-info
alok added inline comments to D99160: [X86][FastISEL] Support DW_TAG_call_site_parameter with FastISEL.
Mar 23 2021, 10:16 PM · Restricted Project, Restricted Project, debug-info
alok added reviewers for D99160: [X86][FastISEL] Support DW_TAG_call_site_parameter with FastISEL: jini.susan.george, SouraVX.
Mar 23 2021, 2:29 AM · Restricted Project, Restricted Project, debug-info
alok requested review of D99160: [X86][FastISEL] Support DW_TAG_call_site_parameter with FastISEL.
Mar 23 2021, 2:21 AM · Restricted Project, Restricted Project, debug-info

Jan 15 2021

alok committed rG104a9f99ccab: [Debuginfo][DW_OP_implicit_pointer] (1/7) Support for… (authored by alok).
[Debuginfo][DW_OP_implicit_pointer] (1/7) Support for…
Jan 15 2021, 1:17 AM
alok closed D84113: [Debuginfo] (1/7) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_implicit_pointer.
Jan 15 2021, 1:17 AM · debug-info, Restricted Project

Dec 5 2020

alok updated the summary of D84113: [Debuginfo] (1/7) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_implicit_pointer.
Dec 5 2020, 3:53 AM · debug-info, Restricted Project
alok updated the diff for D84113: [Debuginfo] (1/7) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_implicit_pointer.

Updated for comment from @jmorse

Dec 5 2020, 3:51 AM · debug-info, Restricted Project

Nov 27 2020

alok abandoned D84114: [Debuginfo] (2/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_explicit_pointer..
Nov 27 2020, 2:33 AM · debug-info, Restricted Project

Nov 26 2020

alok updated the diff for D84115: [Debuginfo][Codegen] (2/7) Support for DW_OP_implicit_pointer for named and unnamed variables (second strategy)..

Updated to incorporate comments from @djtodoro .

Nov 26 2020, 4:29 AM · debug-info, Restricted Project

Nov 23 2020

alok added a comment to D84113: [Debuginfo] (1/7) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_implicit_pointer.

Updated comments from @aprantl and @dblaikie (on other review).

Nov 23 2020, 12:14 AM · debug-info, Restricted Project

Nov 12 2020

alok added reviewers for D84113: [Debuginfo] (1/7) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_implicit_pointer: jini.susan.george, SouraVX.
Nov 12 2020, 2:22 AM · debug-info, Restricted Project
alok added reviewers for D84120: [Debuginfo][SROA] (7/7) Support for DW_OP_implicit_pointer for named and unnamed variables (second strategy).: jmorse, aprantl, jini.susan.george, SouraVX.
Nov 12 2020, 1:58 AM · Restricted Project, debug-info, Restricted Project
alok updated the diff for D84120: [Debuginfo][SROA] (7/7) Support for DW_OP_implicit_pointer for named and unnamed variables (second strategy)..

Updated to re-base.

Nov 12 2020, 1:58 AM · Restricted Project, debug-info, Restricted Project