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 (88 w, 23 h)

Recent Activity

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 · debug-info, Restricted Project
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 · debug-info, Restricted Project

Mar 25 2021

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

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 · Restricted Project, debug-info

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 · Restricted Project, debug-info
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 · Restricted Project, debug-info

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 · Restricted Project, debug-info

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 · Restricted Project, debug-info

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 · Restricted Project, debug-info
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 · 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 · debug-info, Restricted Project
alok updated the diff for D84119: [Debuginfo][mem2reg] (6/7) Support for DW_OP_implicit_pointer for named and unnamed variables (second strategy)..

Updated to re-base.

Nov 12 2020, 1:57 AM · Restricted Project, debug-info
alok added reviewers for D84118: [Debuginfo][Salvaging] (5/7) Support for DW_OP_implicit_pointer for named and unnamed variables (second strategy).: jmorse, aprantl, jini.susan.george, SouraVX.
Nov 12 2020, 1:53 AM · debug-info, Restricted Project
alok updated the diff for D84118: [Debuginfo][Salvaging] (5/7) Support for DW_OP_implicit_pointer for named and unnamed variables (second strategy)..

Updated to re-base.

Nov 12 2020, 1:53 AM · debug-info, Restricted Project
alok updated the diff for D84117: [Debuginfo][FastISel] (4/7) Support for DW_OP_implicit_pointer for named and unnamed variables (second strategy)..

Updated to re-base.

Nov 12 2020, 1:51 AM · debug-info, Restricted Project
alok updated the diff for D84116: [Debuginfo][GlobalISel] (3/7) Support for DW_OP_implicit_pointer for named and unnamed variables (second strategy)..
Nov 12 2020, 1:49 AM · debug-info, Restricted Project
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 re-base and include many comments from @jmorse .

Nov 12 2020, 1:46 AM · debug-info, Restricted Project
alok retitled D84115: [Debuginfo][Codegen] (2/7) Support for DW_OP_implicit_pointer for named and unnamed variables (second strategy). from [Debuginfo] (3/N) Support for DW_OP_implicit_pointer for named and unnamed variables (second strategy). to [Debuginfo][Codegen] (2/7) Support for DW_OP_implicit_pointer for named and unnamed variables (second strategy)..
Nov 12 2020, 1:42 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 comments from @aprantl and @dblaikie (on other review).

Nov 12 2020, 1:39 AM · Restricted Project, debug-info
alok retitled D84113: [Debuginfo] (1/7) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_implicit_pointer from [Debuginfo] (1/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_implicit_pointer to [Debuginfo] (1/7) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_implicit_pointer.
Nov 12 2020, 1:38 AM · Restricted Project, debug-info
alok added a comment to D84114: [Debuginfo] (2/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_explicit_pointer..

Where's the name "explicit" pointer come from? I'm not sure how to read/understand the naming distinction between the names "implicit pointer" and "explicit pointer". Maybe the name should be "LLVM_implicit_pointer" as distinct from the DWARF "implicit_pointer" - that they're roughly the same concept, but the LLVM one is a generalization of it? Or is there something in the implicit/explicit distinction that helps clarify the semantic distinction between the two?

We are using three operators DW_OP_LLVM_explicit_pointer, DW_OP_LLVM_implicit_pointer, DW_OP_implicit_pointer.
Last operator DW_OP_implicit_pointer is dumped to object file and is exact syntax as in DWARF document (DW_OP_implicit_pointer <DIE_reference> <offset_in_DIE>)
Second operator DW_OP_LLVM_implicit_pointer is little variation of DW_OP_implicit_pointer for use till the time the DIE reference is not available with the different syntax (DW_OP_LLVM_implicit_pointer <offset>), where one argument is implicit (first argument of dbg.value intrinsic).

OK, I'm with you so far, that sounds reasonable to me.

While last two operators refer to another variable (Metadata in DW_OP_LLVM_implicit_pointer and DIE reference in DW_OP_implicit_pointer), So this is the variable where we can get the value pointed to by pointer variable (implicit way of getting the value).
The first operator DW_OP_LLVM_explicit_pointer is different than other two operators. This operator is to represent the constant value itself than the other variable and it has the direct way of getting the value pointed to by pointer variable, so the name "explicit" is used.

Sorry, I don't think I'm understanding "This operator is to represent the constant value itself than the other variable and it has the direct way of getting the value pointed to by pointer variable"

Oh, this is for a case where, say, I wrote code like this:

const int *f1() {
  static const int x = 3;
  return x;
}
void f2() {
  const int *y = f1();
  ...
}

Why does that need a different DW_OP compared to DW_OP_LLVM_implicit_pointer? Presumably we use dbg.values for variables with constant values without needing extra operators? (so a variable with the constant value 3 is call void @llvm.dbg.value(metadata i32 3, metadata !11, metadata !DIExpression()) and a variable that /points to/ the constant value 3 would, I would've thought, be call void @llvm.dbg.value(metadata i32 3, metadata !11, metadata !DIExpression(DW_OP_LLVM_implicit_pointer))

though I am open to use any other name.

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

Oct 30 2020

alok added inline comments to D84113: [Debuginfo] (1/7) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_implicit_pointer.
Oct 30 2020, 11:27 AM · Restricted Project, debug-info

Oct 29 2020

alok added inline comments to D89218: [DebugInfo] Support for DW_TAG_generic_subrange.
Oct 29 2020, 5:39 AM · debug-info, Restricted Project
alok committed rGaa71874f6b9b: [DebugInfo] [NFCI] Additional test for support of DW_TAG_generic_subrange (authored by alok).
[DebugInfo] [NFCI] Additional test for support of DW_TAG_generic_subrange
Oct 29 2020, 5:37 AM
alok added inline comments to D89218: [DebugInfo] Support for DW_TAG_generic_subrange.
Oct 29 2020, 3:51 AM · debug-info, Restricted Project
alok committed rG930a8c60b608: [DebugInfo] [NFCI] Adding a missed out line in support for… (authored by alok).
[DebugInfo] [NFCI] Adding a missed out line in support for…
Oct 29 2020, 3:49 AM
alok added inline comments to D89218: [DebugInfo] Support for DW_TAG_generic_subrange.
Oct 29 2020, 3:17 AM · debug-info, Restricted Project

Oct 28 2020

alok committed rGa6dd01afa3d5: [DebugInfo] Support for DW_TAG_generic_subrange (authored by alok).
[DebugInfo] Support for DW_TAG_generic_subrange
Oct 28 2020, 1:09 PM
alok closed D89218: [DebugInfo] Support for DW_TAG_generic_subrange.
Oct 28 2020, 1:09 PM · debug-info, Restricted Project
alok updated the diff for D89218: [DebugInfo] Support for DW_TAG_generic_subrange.

Addressed comments from @aprantl to specialize DIBuilder routine arguments and added tests.

Oct 28 2020, 7:41 AM · debug-info, Restricted Project

Oct 27 2020

alok added a comment to D90243: [NFC] [LLParser] Renaming LLParser routines to satisfy LLVM coding style.

It was huge. Thanks.

Oct 27 2020, 10:31 PM · debug-info, Restricted Project
alok committed rG467db11ccb1c: [NFC] [LLParser] Renaming LLParser routines to comply LLVM coding style (authored by alok).
[NFC] [LLParser] Renaming LLParser routines to comply LLVM coding style
Oct 27 2020, 8:30 PM
alok closed D90243: [NFC] [LLParser] Renaming LLParser routines to satisfy LLVM coding style.
Oct 27 2020, 8:29 PM · debug-info, Restricted Project
alok updated the summary of D90243: [NFC] [LLParser] Renaming LLParser routines to satisfy LLVM coding style.
Oct 27 2020, 9:08 AM · debug-info, Restricted Project
alok requested review of D90243: [NFC] [LLParser] Renaming LLParser routines to satisfy LLVM coding style.
Oct 27 2020, 9:07 AM · debug-info, Restricted Project
alok updated the diff for D89218: [DebugInfo] Support for DW_TAG_generic_subrange.

Addressed concern of @aprantl by getting rid of ConstantAsMetadata and using DIExpression to represent integer type of bounds.

Oct 27 2020, 5:57 AM · debug-info, Restricted Project

Oct 23 2020

alok added a comment to D89817: [DebugInfo] Expose Fortran array debug info attributes through DIBuilder..

Typed the attributes as DIExpression*, as suggested by @aprantl.

Oct 23 2020, 12:52 AM · Restricted Project

Oct 21 2020

alok added inline comments to D89817: [DebugInfo] Expose Fortran array debug info attributes through DIBuilder..
Oct 21 2020, 8:43 AM · Restricted Project
alok added a comment to D84114: [Debuginfo] (2/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_explicit_pointer..

Where's the name "explicit" pointer come from? I'm not sure how to read/understand the naming distinction between the names "implicit pointer" and "explicit pointer". Maybe the name should be "LLVM_implicit_pointer" as distinct from the DWARF "implicit_pointer" - that they're roughly the same concept, but the LLVM one is a generalization of it? Or is there something in the implicit/explicit distinction that helps clarify the semantic distinction between the two?

Oct 21 2020, 12:10 AM · Restricted Project, debug-info

Oct 20 2020

alok added a comment to D89218: [DebugInfo] Support for DW_TAG_generic_subrange.

Cab you remind me why we are allowing ConstantAsMetadata nodes at all instead of allowing only DIExpressions?

Oct 20 2020, 11:19 PM · debug-info, Restricted Project

Oct 16 2020

alok committed rG0538353b3be3: [DebugInfo] Support for DWARF operator DW_OP_over (authored by alok).
[DebugInfo] Support for DWARF operator DW_OP_over
Oct 16 2020, 8:22 PM
alok closed D89208: [DebugInfo] Support for DWARF operator DW_OP_over.
Oct 16 2020, 8:22 PM · Restricted Project, debug-info

Oct 15 2020

alok added a comment to D84114: [Debuginfo] (2/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_explicit_pointer..

hmm, possibly more words in the patch description (& IR documentation). of this and the previous patch - what is implicit_pointer V explicit_pointer? Maybe some examples in the patch description and IR documentation about how they could be used?

Thanks for your comment. I shall update the patch description and IR documentation as well.

Oct 15 2020, 11:39 PM · Restricted Project, debug-info
alok updated the summary of D84114: [Debuginfo] (2/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_explicit_pointer..
Oct 15 2020, 11:38 PM · Restricted Project, debug-info
alok updated the diff for D84113: [Debuginfo] (1/7) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_implicit_pointer.

Updated to re-base and incorporate comment from @dblaikie .

Oct 15 2020, 11:29 PM · Restricted Project, debug-info

Oct 13 2020

alok added inline comments to D89218: [DebugInfo] Support for DW_TAG_generic_subrange.
Oct 13 2020, 4:59 AM · debug-info, Restricted Project
alok updated the diff for D89218: [DebugInfo] Support for DW_TAG_generic_subrange.

Incorporated comments from @djtodoro and also removed function re-naming due to pre-built clang-tidy warnings.
Now all other format warning except first are corrected.

Oct 13 2020, 2:14 AM · debug-info, Restricted Project
alok added inline comments to D89218: [DebugInfo] Support for DW_TAG_generic_subrange.
Oct 13 2020, 1:55 AM · debug-info, Restricted Project
alok added inline comments to D89218: [DebugInfo] Support for DW_TAG_generic_subrange.
Oct 13 2020, 1:06 AM · debug-info, Restricted Project

Oct 12 2020

alok added inline comments to D89218: [DebugInfo] Support for DW_TAG_generic_subrange.
Oct 12 2020, 11:59 PM · debug-info, Restricted Project
alok updated the diff for D89218: [DebugInfo] Support for DW_TAG_generic_subrange.

Updated to re-base, incorporate comment from @SouraVX and changes to pacify pre-built check which expects function names to start with small letter and Variable with capital letter, Newer added function gets created with macro. Changed macro and consequently had to change existing functions.

Oct 12 2020, 11:46 PM · debug-info, Restricted Project
alok added a comment to D89208: [DebugInfo] Support for DWARF operator DW_OP_over.

Can you add an assembler roundtrip test to test/Assembler to test the change to lib/IR?
It just can contain a single named node that holds a DIExpression.

Oct 12 2020, 11:34 PM · Restricted Project, debug-info
alok updated the diff for D89208: [DebugInfo] Support for DWARF operator DW_OP_over.

Updated to re-base and incorporate comment from @aprantl .

Oct 12 2020, 11:34 PM · Restricted Project, debug-info
alok added inline comments to D89218: [DebugInfo] Support for DW_TAG_generic_subrange.
Oct 12 2020, 9:12 AM · debug-info, Restricted Project
alok added a comment to D84114: [Debuginfo] (2/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_explicit_pointer..

hmm, possibly more words in the patch description (& IR documentation). of this and the previous patch - what is implicit_pointer V explicit_pointer? Maybe some examples in the patch description and IR documentation about how they could be used?

Oct 12 2020, 2:34 AM · Restricted Project, debug-info
alok added inline comments to D84113: [Debuginfo] (1/7) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_implicit_pointer.
Oct 12 2020, 2:32 AM · Restricted Project, debug-info
alok added a reviewer for D89218: [DebugInfo] Support for DW_TAG_generic_subrange: djtodoro.
Oct 12 2020, 2:10 AM · debug-info, Restricted Project
alok updated the diff for D89218: [DebugInfo] Support for DW_TAG_generic_subrange.

Updated with comment from @djtodoro

Oct 12 2020, 2:08 AM · debug-info, Restricted Project
alok added inline comments to D89218: [DebugInfo] Support for DW_TAG_generic_subrange.
Oct 12 2020, 1:54 AM · debug-info, Restricted Project

Oct 11 2020

alok requested review of D89218: [DebugInfo] Support for DW_TAG_generic_subrange.
Oct 11 2020, 11:30 PM · debug-info, Restricted Project
alok updated the diff for D89208: [DebugInfo] Support for DWARF operator DW_OP_over.

Re-based,

Oct 11 2020, 11:01 PM · Restricted Project, debug-info
alok requested review of D89208: [DebugInfo] Support for DWARF operator DW_OP_over.
Oct 11 2020, 10:19 AM · Restricted Project, debug-info

Oct 10 2020

alok committed rG96bd4d34a220: [DebugInfo] Support for DWARF attribute DW_AT_rank (authored by alok).
[DebugInfo] Support for DWARF attribute DW_AT_rank
Oct 10 2020, 5:43 AM
alok closed D89141: [DebugInfo] Support for DWARF attribute DW_AT_rank.
Oct 10 2020, 5:43 AM · Restricted Project, debug-info

Oct 9 2020

alok requested review of D89141: [DebugInfo] Support for DWARF attribute DW_AT_rank.
Oct 9 2020, 9:40 AM · Restricted Project, debug-info

Sep 16 2020

alok added a comment to D87500: [DebugInfo] DISubrange support for fortran assumed size array.

Thanks @aprantl for reviewing this. Any idea how to backport it and other fortran related commits to older version of LLVM (11, 10, 9) ?

Sep 16 2020, 1:57 AM · Restricted Project, debug-info
alok committed rG159abe09d25b: [DebugInfo][flang] DISubrange support for fortran assumed size array (authored by alok).
[DebugInfo][flang] DISubrange support for fortran assumed size array
Sep 16 2020, 1:46 AM
alok closed D87500: [DebugInfo] DISubrange support for fortran assumed size array.
Sep 16 2020, 1:46 AM · Restricted Project, debug-info

Sep 12 2020

alok updated the diff for D87500: [DebugInfo] DISubrange support for fortran assumed size array.

Incorporated comment from @aprantl .

Sep 12 2020, 11:46 AM · Restricted Project, debug-info
alok added inline comments to D87500: [DebugInfo] DISubrange support for fortran assumed size array.
Sep 12 2020, 11:07 AM · Restricted Project, debug-info