[flang-commits] [clang] [flang] [FLANG][Driver] Support -fno-profile-generate and -fprofile-generate=<dir> in flang (PR #216643)

[Kaviya Rajendiran via flang-commits]

================
@@ -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