nikic wrote: I think ideally PTO would not depend on the options at all. I believe the way this should work is that PTO is controlled by frontend options, where "frontend" can be clang, but also opt.
We currently have a mix of styles. Some are initialized directly in the PTO options, while some are initialized in the driver, e.g. https://github.com/llvm/llvm-project/blob/cb20860bc31f6a4c0597f1d801cedbbc250fbb94/llvm/tools/opt/NewPMDriver.cpp#L72-L74 And then we have some that do both, like `-floop-interchange` and `-mllvm -loop-enable-loopinterchange` -- the latter of which no longer works now that the former exists. This ends up causing confusion, e.g. when loop interchange was enabled, it was only partially enabled because only some of the defaults got flipped... 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. https://github.com/llvm/llvm-project/pull/237615 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
