[PATCH] D113741: [RFC][DwarfDebug][AsmPrinter] Support emitting function-local declaration for a lexical block

[Kristina Bessonova via Phabricator via llvm-commits]

krisb added a comment.

In D113741#3343849 <https://reviews.llvm.org/D113741#3343849>, @dblaikie wrote:

> In D113741#3343683 <https://reviews.llvm.org/D113741#3343683>, @krisb wrote:
>
>> In D113741#3343496 <https://reviews.llvm.org/D113741#3343496>, @dblaikie wrote:
>>
>>> All good.
>>>
>>> I'm not immediately following why a list of CUs is needed/why we'd create the variable in more than one CU - could you explain that?
>>
>> Well, this is because we may have a parent subprogram emitted in more than one CU (in the case of split dwarf), and we do not know in which one. 
>> Here are the situations I see (hope I got them right):
>> (1) If split dwarf disabled, we have a single list of subprogram's abstract origins and can reference them between CUs. So, we'll emit a concrete definition and its abstract origin (any existing) in the same CU. In this case, we have only one CU.
>> (2) If we have split dwarf enabled, and `shareAcrossDWOCUs()` is false (it's false by default), every CU will maintain its own abstract origin's list. In this case, we cannot have references between CUs, and if we have cross-CU inlining, we'll create:
>>
>> - concrete def -> in the CU the subprogram is defined,
>> - abstract origin -> in every CU the subprogram is inlined. For all local entities we should follow the same logic.
>
> Do you have a test case for this (sorry, I realize it might be one of the test cases in the patch - I haven't looked/would appreciate some pointers)? My recollection is that without shareAcrossDWOCUs we should probably be only emitting one CU if using Split DWARF - Split DWARF doesn't really support multiple CUs in a single .dwo file (& we only support emitting a single .dwo for a given .o file) - but I guess maybe we do in full LTO mode, even if we don't do it in ThinLTO mode (ThinLTO's the only thing I've been especially concerned with/the only mode we use at Google)?

I was inspired by these two tests:

  LLVM :: DebugInfo/X86/split-dwarf-cross-cu-gmlt-g.ll
  LLVM :: DebugInfo/X86/split-dwarf-cross-unit-reference.ll

They test the case I described in (2), with 2 CUs in a single .dwo.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113741/new/

https://reviews.llvm.org/D113741