[PATCH] D59923: [Driver] Simplify -g level computation and its interaction with -gsplit-dwarf

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

In D59923#1447198 <https://reviews.llvm.org/D59923#1447198>, @MaskRay wrote:

> In D59923#1446508 <https://reviews.llvm.org/D59923#1446508>, @dblaikie wrote:
>
> > What's the general motivation for this work/changes?
>
>
> The current -gsplit-dwarf handling is a bit complex and the motivation is to make it less confusing.
>
>   -g0 -gsplit-dwarf => 2
>   -gmlt -gsplit-dwarf -fsplit-dwarf-inlining => 2
>   -gmlt -gsplit-dwarf -fno-split-dwarf-inlining => 1 (before) 2 (after)
>   
>
> It is confusing because the composition of `-gmlt -gsplit-dwarf` is different from `-g0 -gsplit-dwarf` when `SplitDWARFInlining` is false.
>
> >> -gmlt -gsplit-dwarf -fno-split-dwarf-inlining => special: 1 (before) 2 (after)
> > 
> > This ^ is the only semantic change due to this refactoring?
>
> This is the only semantic change.
>
> > There's a desire to be able to compose gmlt+gsplit-dwarf, /if/ -fno-split-dwarf-inlining is enabled. (for context, -fno-split-dwarf-inlining is the default in Google's optimized builds, since split-dwarf-inlining was never implemented in GCC & we didn't want to regress object size when switching from GCC to Clang (& no one had complained about that missing functionality))
> > 
> > So with -fno-split-dwarf-inlining, there's value in using gmlt with gsplit-dwarf (it reduces the size of the .dwo files - reducing the inputs/size of dwp, etc).
> > 
> > & it sounds like this change breaks that scenario?
>
> Acknowledged the desire to compose `-gsplit-dwarf -gmlt -fno-split-dwarf-inlining`. After this patch, users should place `-gmplt` after `-gsplit-dwarf`.
>
> In Bazel, the order of the command line options from left to right: feature flags < BUILD `copts=` < `--copt=`. So for targets specifying `-g0`/`-gmlt` in their `copts` / explict `--copts=` options, they will override `-gsplit-dwarf` added by the debug feature.


OK - could you include/describe which sets of options disable split-dwarf, then? (adding that to the patch description along with the matrix of g1/2, etc? (specifically, I'd expect "-gmlt -gsplit-dwarf" means 2+split, "-gsplit-dwarf -gmlt" means 1+non-split, and "-fno-split-dwarf-inlining -gsplit-dwarf -gmlt" (with -fno-split-dwarf-inlining anywhere in the command line (so long as it's after an -fsplit-dwarf-inlining) is 1+split)

I'm still not quite sure changing the meaning of "-gmlt -gsplit-dwarf -fno-split-dwarf-inlining" is important. It feels to me like in that mode, -gmlt and -gsplit-dwarf compose naturally in either order. Is it code complexity or user interface complexity you're trying to address? I'm still a bit curious/trying to better understand the motivation here.


Repository:
  rC Clang

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

https://reviews.llvm.org/D59923