The use model for CS IRPGO is
IRPGO-gen → training-run → IRPGO-use + CS IRPGO-gen → training run → IRPGO-use + CS IRPGO-use →
The purpose of CS IROGO in this way is to do instrumentation post-inlining so that more accurate (context sensitive) profile data can be collected.
We plan to develop a new IR PGO algorithm that can combine the current IRPGO and CSIRPGO.
-fsamlpe-use and -fauto-profle are aliases, so no there is no difference.
-fprofile-sample-accurate and -fauto-profile-accurate are aliases too.
History: we first added AutoFDO support in GCC with -fauto-profile etc options. This was ported to LLVM later with new options, but the GCC flavor was kept too.
Am I right that now there is no reason to use CS IRPGO without IR PGO?
The model of using CS IRPGO alone is supported and depending on the scenarios, it may or may not perform better than regular IRPGO. In short, there is no clear advantage of using this mode.
I’ve actually found that in some scenarios, CS IRPGO has less instrumentation overhead than IRPGO due to injecting code after inlining, making it useful alone.