[clang] [llvm] [DTLTO] Serialize of LTO Config (PR #219894)

[Konstantin Belochapka via cfe-commits]

kbelochapka wrote:

> > > e.g., #220053
> > > In particular anything ABI influencing shouldn't be buried in an LTO specific config
> > 
> > 
> > Hi @arsenm, Could you please elaborate on what, in your opinion, needs to be done?
> 
> More deletion of TargetOptions. Some without replacement, some with semantically designed and documented module flag replacements. e.g., I recently removed TargetOptions::FloatABI with a new "float-abi" module flag. Some other flags probably shouldn't exist, or be restricted to tool driver debug flags.
> 
> > How can we ensure that removing any field from `lto::Config` or `llvm::TargetOptions` serialization does not eventually affect code generation?
> 
> You have to evaluate this case-by-case.
> 
> > What mechanism or process would prevent such regressions?
> 
> Deleting TargetOptions, which will take a while. We could add a static_assert to prevent anyone from adding a new field. We can comment to stop introducing uses, but that may not be the most effective without a hard enforcement. But we've been making slow but steady progress on this (e.g., the fast math fields are close to removal)

Hi @arsenm,
As I understand it, there is a long-term plan to eventually eliminate llvm::TargetOptions.
Given that, what do you think we should do in the short term? What are your thoughts on Steven's proposed solution?

> To be explicit I think this is moving in the wrong direction and is not a viable starting point. Toolchain machinery flags should not be serialized, and any semantic or ABI influencing options need white-glove, independent treatment

Hi @arsenm ,
Since all fields are defined through macros, we can easily extend the macros with an additional parameter that specifies whether a given field is subject to serialization. It appears that we need serialize different fields for different purposes.

https://github.com/llvm/llvm-project/pull/219894