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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
