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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
