RFC: Add -p driver support to Clang

I am trying to compile with -p with clang on AIX, but the flag isn’t supported; even though gcc supports it on both Linux and AIX.

The purpose of the -p flag is similar to that of -pg, but the results are analyzed with the prof tool (on AIX, a mon.out file is generated) as opposed to gprof (on AIX, a gmon.out file is generated). gcc also acknowledges the existence and purpose of -p and the prof tool: https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#Instrumentation-Options

In terms of implementation, the only difference between -p and -pg would be the link invocation on the driver. For example, xlC and GCC on AIX link against gcrt0.o for -pg and against mcrt0.o for -p.

On Linux, GCC outputs gmon.out files for both -p and -pg, but Clang ignores -p while it outputs gmon.out for -pg.

Clang already has an option for -p. However, while the Clang driver implementation for the AIX toolchain recognizes the flag and correctly links against mcrt0.o, it still complains with warning: argument unused during compilation: ‘-p’ if the invocation involved compiling code (pure link invocations don’t generate the warning). mcount instrumentation calls are also not inserted because it is not recognized properly.

I’m proposing a change that, when passed -p on AIX, would remove the warning and insert the mcount instrumentation calls. We could also make Clang more like GCC on platforms like Linux, so -p behaves like -pg. This can be achieved by having the driver pass -pg to the front-end in response to the -p option.

I think it would be reasonable to make clang handle -p like GCC on all platforms.

+1 to following gcc precedent.

This seems reasonable to me.

Instrumentation Options (Using the GNU Compiler Collection (GCC)) says

Generate extra code to write profile information suitable for the analysis program prof (for -p) or gprof (for -pg). You must use this option when compiling the source files you want data about, and you must also use it when linking.

In practice, at least on linux-gnu triples, it seems that -p is just an alias for -pg in GCC. Currently Clang accepts and ignores -p. For GCC compatibility making -p an alias for -pg makes sense, but I wish that we can pause and think whether adding -p to do something is really useful as I get some legacy feeling when reading things about -p. Is this an AIX vendor can do to help migrate away from -p?

Note that on FreeBSD GCC -p for the link action gives this notice gcc: note: consider using '-pg' instead of '-p' with gprof(1). I think I am inclined that if AIX really wants it, make it AIX specific.

With OpenBSD we have a diff like the following in our tree…

Index: tools/clang/include/clang/Driver/Options.td
--- tools/clang/include/clang/Driver/Options.td.orig
+++ tools/clang/include/clang/Driver/Options.td
@@ -3721,7 +3733,7 @@ defm pthread : BoolOption<"", "pthread",
   LangOpts<"POSIXThreads">, DefaultFalse,
   PosFlag<SetTrue, [], "Support POSIX threads in generated code">,
   NegFlag<SetFalse>, BothFlags<[CC1Option]>>;
-def p : Flag<["-"], "p">;
+def p : Flag<["-"], "p">, Alias<pg>;
 def pie : Flag<["-"], "pie">, Group<Link_Group>;
 def static_pie : Flag<["-"], "static-pie">, Group<Link_Group>;
 def read__only__relocs : Separate<["-"], "read_only_relocs">;

Thank you. So it seems like we can include OpenBSD in the set of cases where the functional behaviour of -p matches that of -pg.

I agree. We may not know what GCC does on some platforms though (and I think those cases should produce an error).

Why is it desirable to accept and ignore with just a warning? The status quo is suspect in itself.

If a user meant to get a profile, then it potentially wastes the user the time spent compiling the wrong configuration (and likely also the time spent for their first attempt at collecting the profile too). Even worse, they may compile with Clang for some static libraries and link using GCC: In such a case, it is possible (and on some platforms, it is known to be true) that they can get profiling output, but it would be incomplete in ways that are not immediately obvious. If you believe -p should not function (except for vendors that specifically want it), then it probably should trigger an error.

Additionally, -p being less comprehensive, in some sense, also means that there is potentially less overhead and resource cost. On AIX, I have seen -p generate files that are 10% smaller than those from -pg.

Can you identify whether -p and -pg are functionally different on FreeBSD? The note " consider using '-pg' instead of '-p' with gprof(1)" may merely mean that using gprof is a given on the platform (-p generates -pg output) and -pg is a better match for that fact.

I think the current state is undesired. Either -p should be rejected or it should behave like -pg. I somewhat incline to rejection as there is evidence this has been a legacy option for many years and I suspect there isn’t many usage. The fact that it’s a short option makes it difficult to know how much it is used, though.
I think on FreeBSD and Linux gcc -p just acts as an alias for -pg. I am still thinking whether vendors can do something to not make an uncommon short option -p not an alias: for a feature I think it’s good to avoid too many spellings, especially a difficult-to-find short option.

For platforms where it is an alias, it really comes down to whether GCC compatibility means the option should be accepted (and functional). For platforms where it is not an alias, not implementing -p means missing functionality (because on those platforms, prof exists and has not been removed in favour of gprof). Implementing -p as an alias for -pg on the platforms where GCC treats -p as separate would be dubious.