[PATCH] D21823: [Driver] Add flags for enabling both types of PGO Instrumentation

[Sean Silva via cfe-commits]

silvas added inline comments.

================
Comment at: lib/Driver/Tools.cpp:3560
@@ +3559,3 @@
+    if (PGOTrainArg->getOption().matches(options::OPT_fpgo_train_EQ)) {
+      if (StringRef(PGOTrainArg->getValue()) == "source-cfg")
+        CmdArgs.push_back("-fprofile-instrument=clang");
----------------
davidxl wrote:
> I think it is better to make the selector  'source' vs 'cfg'.    
> 
> -fpgo-train=source
> -fpgo-train=cfg
So would `-fpgo-train=cfg` enable icall instrumentation or not?

My thinking is that down the road we will have one flag for each independent instrumentation capability (and of course some are mutually incompatible). This mirrors what the sanitizers do. For example, we would have:
`-fpgo-train=optimizer-cfg` --> IR edge profiling
`-fpgo-train=optimizer-icall` --> IR icall value profiling
`-fpgo-train=optimizer-...` --> other independent instrumentation we can do in IR instrumentation.
`-fpgo-train=source-cfg` --> FE edge profiling
`-fpgo-train=source-icall` --> FE icall profiling (if that even exists; I see some code but there is no user-visible flag)
`-fpgo-train=source-...` --> other FE instrumentation.

We can then have `-fpgo-train=optimizer` enable e.g. `-fpgo-train=optimizer-cfg,optimizer-icall`.
We can also have `-fpgo-train=source` enable e.g. `-fpgo-train=source-cfg`.

Since instrumentation can have different overheads or different runtime requirements, users may want to disable some instrumentation.


Repository:
  rL LLVM

http://reviews.llvm.org/D21823