This patch adds flags and tests to cover the PGOOpt handling logic in new PM.
Details
Diff Detail
- Build Status
Buildable 8535 Build 8535: arc lint + arc unit
Event Timeline
Awesome, I'm glad to see a nice way of testing this at a low level!
lib/Passes/PassBuilder.cpp | ||
---|---|---|
175–178 | Rather than these options going in PassBuilder.cpp and overriding things, I think this should go into tools/opt/NewPMDriver.cpp much like the ThinLTO controls do. Then the opt tool can construct a PGOOpt struct and hand it into the PassBuilder much the same way Clang will. Also, sample_gen doesn't appear to be valid? I think rather than having one flag that you have to parse I would suggest have three flags: pgo-instr-gen, pgo-intsr-use, and pgo-sample-use. I think there is a way in the cl::opt layer to say the flags are mutually incompatible, but even if you have to do that manually, it seems better than parsing an '=' out of the flag value. |
lib/Passes/PassBuilder.cpp | ||
---|---|---|
175–178 | pgo-instr-{gen|use}, conflict with existing flags. Used pgo-{gen|use|sample-use} instead. |
Minor flag tweak...
tools/opt/NewPMDriver.cpp | ||
---|---|---|
168–170 ↗ | (On Diff #108167) | What about a simpler factoring of flags: cl::opt<PGOKind> PGOKindFlag( cl::values(clEnumValN(PGOKind::InstrGen, "new-pm-pgo-instr-gen-pipeline", "..."), clEnumValN(PGOKind::InstrUse, "new-pm-pgo-instr-use-pipeline", "..."), clEnumValN(PGOKind::SampleUse, "new-pm-pgo-sample-use-pipeline", "..."))); cl::opt<std::string> ProfileFile(...); This would do the checking that only one kind is selected at a time for you I think. |
I think the command line flags can be made simpler, but I must not be explaining it well in review. I suggest you go ahead and submit this and I'll immediately send you a follow-up patch that hopefully illustrates what I'm suggesting for handling the flags. And that will let you rebase and continue on other things.
Rather than these options going in PassBuilder.cpp and overriding things, I think this should go into tools/opt/NewPMDriver.cpp much like the ThinLTO controls do.
Then the opt tool can construct a PGOOpt struct and hand it into the PassBuilder much the same way Clang will.
Also, sample_gen doesn't appear to be valid?
I think rather than having one flag that you have to parse I would suggest have three flags: pgo-instr-gen, pgo-intsr-use, and pgo-sample-use. I think there is a way in the cl::opt layer to say the flags are mutually incompatible, but even if you have to do that manually, it seems better than parsing an '=' out of the flag value.