hubert.reinterpretcast added inline comments.
================ Comment at: clang/test/Driver/ppc-roptr.c:10 +// ROPTR-NOT: "-mroptr" +// ROPTR-NOT: "-bforceimprw" + ---------------- hubert.reinterpretcast wrote: > w2yehia wrote: > > hubert.reinterpretcast wrote: > > > Do we pass the option through to the LTO codegen when > > > `-fprofile-generate` is used? > > > We may need a driver diagnostic for `-mroptr` without data sections when > > > linking LTO objects (because the front-end won't be involved). > > > > > > @w2yehia, does LLVM trunk have a gap in LTO driver enablement for AIX? > > > does LLVM trunk have a gap in LTO driver enablement for AIX? > > > > I think trunk is up to date in terms of LTO (driver and libLTO); this was > > done in LLVM 16.0. > > > > > Do we pass the option through to the LTO codegen when -fprofile-generate > > > is used? > > > > what's special with -fprofile-generate in relation to the ROPTR option? > Sorry, I meant on the LTO link step. It seems to me that we don't pass the option through to the LTO codegen on the LTO link step (which is a problem). It also seems that there is no diagnostic generated (would likely hit the back-end assertion/error) when `-fno-data-sections` and `-mroptr` is specified at the same time for the LTO link step. I believe a driver diagnostic needs to be added. I am of the opinion that we don't have to have a front-end diagnostic in addition to a driver diagnostic if the back-end will error out in the case where relevant codegen is encountered (it provides an esoteric way to quickly check if relevant codegen is involved for a given source file). We should apply the same policy between `clang -cc1` and `llc` though. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D144190/new/ https://reviews.llvm.org/D144190 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
