[PATCH] D106582: [DebugInfo] Add -fno-ctor-homing for as counterpart to -fuse-ctor-homing

David Blaikie via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Jul 22 13:21:02 PDT 2021


dblaikie added a comment.

In D106582#2897678 <https://reviews.llvm.org/D106582#2897678>, @akhuang wrote:

> In D106582#2897599 <https://reviews.llvm.org/D106582#2897599>, @dblaikie wrote:
>
>> Looks alright to me. (bit awkward having a documented cc1 option - since the cc1 options aren't meant to be user facing - hadn't really thought about/noticed that when reviewing the documentation originally in D95911 <https://reviews.llvm.org/D95911>)
>
> Oh, true. Since we're making ctor homing default maybe I should just make them user facing flags.

I have mixed feelings - on the one hand, yeah, we're changing the behavior of `-fno-standalone-debug` and giving people a tool to undo that change if it's problematic is good (less chance we have to churn through reverting the change, fixing, reapplying, etc, if there's a way to opt-out, at least in the short term). But equally I don't want to proliferate various rather arbitrary buckets of debug info type homing - I really want to encourage people to think of it as a fairly all-or-nothing situation, because I don't think there's a good way to explain/improve/modify/use the feature if it's "whatever is good enough for my use case". Especially now that there's the `standalone_debug` attribute that can be used to fix particular use cases where a type is needed across a `-g0` boundary.

So... eh. Could go either way - your call, really. Though if we make it a full driver option, maybe a caveat that we may remove the functionality in the future (but that'll mean probably having to leave the flag in as a no-op/with some deprecation warning for some time after removing the functionality).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106582



More information about the cfe-commits mailing list