Different training algorithms may produce models that, besides the main
policy output (i.e. inline/don't inline), produce additional outputs
that are necessary for the next training stage. To facilitate this, in
development mode, we require the training policy infrastructure produce
a description of the outputs that are interesting to it, in the form of
a JSON file. We special-case the first entry in the JSON file as the
inlining decision - we care about its value, so we can guide inlining
during training - but treat the rest as opaque data that we just copy
over to the training log.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Analysis/DevelopmentModeInlineAdvisor.cpp | ||
---|---|---|
63–67 | what's the motivation of providing this override alternative? | |
654–668 | I'm a bit confused here, why we need both MUTR and Runner in the TrainingLogger? Are they just the same? (why not using ModelRunner instead of MUTR in all TrainingLogger functions?) | |
llvm/lib/Analysis/models/inliner/output_spec.json | ||
2–14 | where is this file being used? Is it used when running default policy? |
llvm/lib/Analysis/DevelopmentModeInlineAdvisor.cpp | ||
---|---|---|
63–67 | Testing. See the added run in development-training-log.ll | |
654–668 | Runner is generically typed as MLModelRunner, which could be either a ModelUnderTrainingRunner or the NoInferenceModelRunner, see lines 659 and 661. | |
llvm/lib/Analysis/models/inliner/output_spec.json | ||
2–14 | It is used alongside the pre-trained policy, for example in one of the current runs in tests (incl. development-training-log.ll's current test that uses that model. |
llvm/lib/Analysis/DevelopmentModeInlineAdvisor.cpp | ||
---|---|---|
654–668 | ha, I see, but the APIs here looks quite confusing to me...Would it be better to add some APIs in NoInferenceModelRunner such that we don't need two different ModelRunner here? |
llvm/lib/Analysis/DevelopmentModeInlineAdvisor.cpp | ||
---|---|---|
654–668 | you mean no-op apis to NoInferenceModelRunner? we can look into it after this CL, so we make sure the whole functionality would work in that case (and see what the usage would look like, wouldnit actually be simpler, etc) |
llvm/lib/Analysis/DevelopmentModeInlineAdvisor.cpp | ||
---|---|---|
406 | Outputs.resize(MUTR->outputSpecs().size()) or Outputs.assign(MUTR->outputSpecs().size(), std::vector<char>()) |
feedback
llvm/lib/Analysis/DevelopmentModeInlineAdvisor.cpp | ||
---|---|---|
406 | yup, that's cleaner - thanks! |
what's the motivation of providing this override alternative?