================
@@ -497,8 +497,18 @@ static void
parseCodeGenArgs(Fortran::frontend::CodeGenOptions &opts,
opts.IsPIE = 1;
}
- if (args.hasArg(clang::options::OPT_fprofile_generate)) {
- opts.setProfileInstr(llvm::driver::ProfileInstrKind::ProfileIRInstr);
+ if (const llvm::opt::Arg *a =
----------------
kaviya2510 wrote:
> -fc1 is not intended to be called directly by end users. We should not be
> exposing all driver options to it - only those that are required. For that
> same reason, we should not be duplicating error checking in both places. We
> often do because no one likes catastrophic failures, but it is reasonable for
> the compiler to expect to find certain options.
Thankyou for the clarification.
> If you look at the implementation in clang, the -profile-* options are
> handled in clang/lib/Driver/ToolChains/Clang.cpp. In fact, we should try to
> reuse that code if possible rather than reimplementing it. This may require
> moving some of it to CommonArgs.cpp, but there is plenty of precedent for
> that.
I agree with you. In Clang, `addPGOAndCoverageFlags(..)` handles all profiling
options and translates them to the appropriate `-fprofile-instrument=<value>`
and pass it to`-cc1`. Since Clang supports multiple profiling modes
(source-based, IR-based, CS-PGO, etc.), it makes sense to resolve everything at
the driver level.
Currently, Flang only supports IR-based profiling and the existing
`-fprofile-generate` implementation is handled directly in -fc1. Given the
limited scope, would it be acceptable to keep the current approach for now and
refactor into a shared function in `CommonArgs.cpp` once Flang's profiling
support grows?
https://github.com/llvm/llvm-project/pull/216643
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
