This patch adds flags and tests to cover the PGOOpt handling logic in new PM.
Details
Diff Detail
- Build Status
Buildable 8587 Build 8587: arc lint + arc unit
Event Timeline
This is a step in the right direction, some comments inline.
lib/Passes/PassBuilder.cpp | ||
---|---|---|
1109 ↗ | (On Diff #107927) | s/Use/Process/ ? |
1116 ↗ | (On Diff #107927) | Do you need return after fatal? |
1118 ↗ | (On Diff #107927) | Capital P |
1120–1135 ↗ | (On Diff #107927) | StringSwitch maybe? |
Awesome, I'm glad to see a nice way of testing this at a low level!
lib/Passes/PassBuilder.cpp | ||
---|---|---|
175–178 ↗ | (On Diff #107939) | 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 ↗ | (On Diff #107939) | pgo-instr-{gen|use}, conflict with existing flags. Used pgo-{gen|use|sample-use} instead. |
Minor flag tweak...
tools/opt/NewPMDriver.cpp | ||
---|---|---|
168–170 | 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.
What about a simpler factoring of flags:
This would do the checking that only one kind is selected at a time for you I think.