OK. Now I understand what you meant. I was trying to avoid driver changes. It seems you are saying I can change the driver to support cc1 options more cleanly. This can be done.
Thanks, Rong On Jan 25, 2016 12:43, "Sean Silva" <chisophu...@gmail.com> wrote: > silvas added inline comments. > > ================ > Comment at: lib/Frontend/CompilerInvocation.cpp:487 > @@ +486,3 @@ > + // Opts.ProfileInstrGenerate will be used for Clang instrumentation > only. > + if (!Opts.ProfileIRInstr) > + Opts.ProfileInstrGenerate = Args.hasArg(OPT_fprofile_instr_generate) > || > ---------------- > davidxl wrote: > > xur wrote: > > > silvas wrote: > > > > I don't like this. It breaks the 1:1 mapping of flags to codegen > options. Like Chad said, this sort of complexity should be kept in the > driver. > > > > > > > > Some refactoring may be needed to cleanly integrate the new IR > instrumentation. > > > hmm. I don't think there is 1:1 mapping b/w flags and codegen options, > because -fprofile-instr-generate is shared by IR and FE instrumentation. > > If you rename the FE PGO CodeGen opt name as proposed, it will be > clearer and less confusing. > > hmm. I don't think there is 1:1 mapping b/w flags and codegen options, > because -fprofile-instr-generate is shared by IR and FE instrumentation. > > Maybe at the driver level (that discussion has yet to conclude), but at > cc1 level options should be factored to be clean and orthogonal. Like Chad > said, the complexity of verifying options that are mutually exclusive or > that must be present with other options should be done in the driver. cc1 > is a private interface > > > > http://reviews.llvm.org/D15829 > > > >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
