MaskRay wrote: > So an alternative to the LibraryOptions dependency here would be to remove > the reliance on options entirely.
> TBH I think that some of these pipeline tuning options should just be > dropped. I have no idea why things like > LicmMssaOptCap/LicmMssaNoAccForPromotionCap are in here at all. These seem > like details that should just be normal cl::opt options. I think this might > be an artifact of some people thinking that all the pass cl::opts should > actually be pass options, which then also requires threading them through as > pipeline tuning options. But I think with the work on LibraryOptions, this is > probably not a useful view anymore, and we should not use pass options unless > we actually do want to pass different options at different points in the same > optimization pipeline. I agree. #232599 added `PipelineTuningOptions(const cl::LibraryOptionsContext *);` as a makeshift for per-context library option support. The ctor should not have been added. Regarding LicmMssaOptCap/LicmMssaNoAccForPromotionCap, these knobs that tune passes should not live in PipelineTuningOptions, but they are out of scope the my library option work. Created #238434 to remove `PipelineTuningOptions(const cl::LibraryOptionsContext *);`. It's API-compatible with the state before the introduction of per-context library options. https://github.com/llvm/llvm-project/pull/237615 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
