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? https://github.com/llvm/llvm-project/pull/219894 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
