[PATCH] D94655: [Driver] -gsplit-dwarf: Produce .dwo regardless of -gN for IR input

Thu Jan 14 09:48:10 PST 2021

dblaikie added a comment.

In D94655#2498548 <https://reviews.llvm.org/D94655#2498548>, @MaskRay wrote:

> In D94655#2498504 <https://reviews.llvm.org/D94655#2498504>, @dblaikie wrote:
>
>> Is there any way to condition this on the type of the output, rather than the input? (or, more specifically, on whether machine code is being generated)
>>
>> Or maybe we could always pass the split-dwarf-file down through LLVM and not need to conditionalize it at all? It'd be a no-op if there's no DWARF in the IR anyway?
>
> I tried replacing `if (IRInput || Args.hasArg(options::OPT_g_Group)) {` with `if (1)`, -gsplit-dwarf may produce .dwo for regular non-g .c compile.

Are you saying that if you make that change -gsplit-dwarf does cause .dwo files to be created for non-g .c compiles? Do the dwo files have anything in them? I had modified llvm to dynamically choose split or non-split based on whether there was enough data to be worth splitting into a .dwo file, but I guess that situation might still be producing an empty .dwo file which isn't ideal - I haven't tested that.

> Since we already have the
>
>   // For -g0 or -gline-tables-only, drop -gsplit-dwarf. This gets a bit more
>   // complicated if you've disabled inline info in the skeleton CUs
>   // (SplitDWARFInlining) - then there's value in composing split-dwarf and
>   // line-tables-only, so let those compose naturally in that case.
>
> logic, I think altering `DwarfFission` in the driver is fine. If not, I'd hope the backend to process `DwarfFission` ...

Sorry, I'm not understanding this comment - could you describe/rephrase it in more detail?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94655