mstorsjo wrote:
> Doesn't UseInitArray default to false in LLVM?
The class `TargetOptions` itself initializes it to false indeed. But
`codegen::InitTargetOptionsFromCodeGenFlags` (which seems to be what e.g. `llc`
uses) explicitly sets it to `!getUseCtors()`, which only checks the state of
the `-use-ctors` option. And Clang sets it unconditionally based on the codegen
option with the same name, which defaults to true and is controlled by the
`-f[no-]use-init-array` option.
> Anyway, we already have ways to make booleans optional; it's just a matter of
> implementing a "default" state, which we already do for certain options like
> code models. I don't think there's any fundamental architectural work
> involved in doing that. (See various enums in TargetOptions.h)
Right, so adding an `enum DefaultableBool { Default, False, True }` and
changing the field to that value? That'd be an API break for all users of the
struct, but which should be allowed for us to do? All users of `TargetOptions`
would need to change from passing regular bools to passing values from this
enum - and at the same time, they get reminded that they can keep it set to
`Default` in case they don't really have a strong opinion on the matter. Is
that what you had in mind? Or is there a way to make the migration smoother for
users somehow?
It sounds like a somewhat disruptive change for downstreams; I know we're not
supposed to compromise upstream design too much around downstream concerns, but
it feels somewhat like making more of a fuss than I wanted...
https://github.com/llvm/llvm-project/pull/68571
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
