[PATCH] D80391: [Driver] Don't make -gsplit-dwarf imply -g2

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

In D80391#2497073 <https://reviews.llvm.org/D80391#2497073>, @MaskRay wrote:

> From @dblaikie's email reply:
>
>> ^ this I would consider to be a bug. -g should be needed to generate debug info into the IR, and -gsplit-dwarf should be needed to choose how debug info already in the IR should be placed into object files or dwo files.
>>
>> Usually (non-LTO) these two steps are in the same compile, so -g and -gsplit-dwarf go together. But for LTO cases, I think it's suitable for -g to be needed for IR generation, and -gsplit-dwarf to be needed for object code generation, without needing -g as well in that latter step (the -g was already specified at IR generation time, and that shoul be enough).
>>
>> We can see that behavior I'm describing as desirable in implicit ThinLTO I showed earlier in the thread.
>>
>> I suggest this should be the desired behavior, because -g generally has no effect on IR->object code generation, so it seems strange/unnecessary to me to gate -gsplit-dwarf behind -g in that case. The -g was already specified and used during IR generation (& the -gN level, -gmlt behavior-etc has all been handled in IR generation (or embedded in the IR for use later) - so to me, specifying -g again during object code generation would be/is strange, because any special values would be ignored (-g1/g2/g3/etc would not be respected - the N value would only be respected when passed to the IR generation step))
>
> Got it. `-fthinlto-index=` (thinlto backend compile) operates on bitcode files and does not IR generation. It isn't suitable for `-g` to be needed to use.
> -gsplit-dwarf is both an IR generation option and an object file generation option. It is needed for thinlto backend compiles.

(sounds like we're mostly on the same page now - minor note though: I don't think -gsplit-dwarf is an IR generation option. I don't think it has any effect on IR generation - I believe the IR is exactly the same whether it ends up being used with split or unsplit DWARF generation)

> In Bazel, I think a typical configuration's `LTO Backend Compile` includes almost every option in the initial compile, so I did not notice the issue. I am working on a patch.

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80391