Currently there is no way to add in development features to the ML
regalloc evict advisor which is useful to have when working on feature
engineering/improving the current model. This patch adds in the ability
to add in development features to the ML regalloc evict advisor which
are gated by a runtime flag and not added in at all if not compiled in
LLVM development mode. This sets the stage for future work where we are
planning on upstreaming some of the newer features that we are currently
experimenting with.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This patch adds in a DEVELOPMENT_RA_EVICT_FEATURES_LIST macro that contains development features and modifies/refactors the reset of the file in order to be able run these features when the command line option enable-features-under-development is specified. I tested this in release mode and development mode when compiled in MLGO development mode (setting TENSORFLOW_C_LIB_PATH) and I did another build in release mode (LLVM_HAVE_TF_API is false, TENSORFLOW_C_LIB_PATH isn't set) and everything seemed to work correctly, but it definitely wouldn't hurt to have more people testing this change.
Is the main goal of the patch enabling a runtime-determined set of features, to avoid the overhead of allocating buffers for unused features? If yes, I'd just scope it at that change: making the feature storage a vector, and simplifying TrainingInputFeatures as such.
Then I'd just add the change you have in mind, i.e. skip having a 'dummy feature'.
llvm/lib/CodeGen/MLRegallocEvictAdvisor.cpp | ||
---|---|---|
201 | I don't understand how this is used: if the issue is figuring out if we are doing release or development, we can just check the type of the advisor or of the evaluator? |
Reduced the scope of the change to just refactoring parts of the
MLRegallocEvictAdvisor to set the stage for future work involving
feature lists that vary at runtime.
llvm/lib/CodeGen/MLRegallocEvictAdvisor.cpp | ||
---|---|---|
335 | don't init the static in the ctor. Init it outside (i.e. it can be init-ed where it was before) also, why make it a member? that seems unrelated change | |
343 | no need to make it a member / or separate change. | |
402 | same as above: don't init statics in the ctor, etc. |
llvm/lib/CodeGen/MLRegallocEvictAdvisor.cpp | ||
---|---|---|
335 | I've moved the initialization of InputFeatures and TrainingInputFeatures to the constructors of the Analyses that use them because adding extra features at runtime requires the modification of these vectors at runtime. I've kept them as static to share a single copy per analysis across the entire invocation of LLVM (although I don't believe it should matter as if I'm understanding everything correctly, there's only one analysis created per invocation). I've moved them to being class members as I believe it makes reading the code more clear (versus sharing commonalities between the advisors and then extending the vectors in the constructors), but I can change it around if desired. This is necessary for the goal of the patch (refactoring to allow for runtime enabled features) if I'm not mistaken and there isn't some approach I'm unaware of, but I can rescope if desired. |
llvm/lib/CodeGen/MLRegallocEvictAdvisor.cpp | ||
---|---|---|
335 | Ack on the initialization, but let's not make them static then. The analysis is shared, indeed. |
Changed InputFeatures and TrainingInputFeatures from being static members to
normal class members.
I don't understand how this is used: if the issue is figuring out if we are doing release or development, we can just check the type of the advisor or of the evaluator?