Details
- Reviewers
dblaikie - Commits
- rGda9244882804: [NFC][MLInliner] Presort instruction successions.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Looks good - thanks!
Few other bits of optional feedback, I don't mean to dredge up old code that I know we discussed somewhat in the past - but some thoughts in case any resonate/make more sense now than in the past, and some minor bits of stuff that can be cleaned up without pre-commit review.
llvm/lib/Analysis/InlineSizeEstimatorAnalysis.cpp | ||
---|---|---|
85–87 | Could replace this with llvm::is_sorted(FunctionFeatures::ImportantInstructionSuccessions); while you're here | |
96 | This could be a static variable here ^ rather than being a member variable - would save all the IRToNativeSizeLearning::FunctionFeatures:: qualification - doesn't look like that qualification adds a lot of value to the variable name? (I tend to think "longer variable names for wider scopes" - given the effective scope of this variable is just two functions here - maybe doesn't need such a long name (at least the qualifiers, "ImportantInstructionSuccessions" is probably sufficiently unambiguous?) | |
130–133 | Throughout the file there are a fair few non-const references that could be const, which would be preferred. (generally top level const on local values is less interesting - but usually if a reference can be const, it should be made so) | |
165–167 | 'int' would be appropriate here - 'auto' isn't helping readability, it's longer than 'int' | |
168–169 | Could simplify this a bit with llvm::find(FunctionFeatures::ImportantInstructionSuccessions, std::make_pair(a, b)) - separate commit, doesn't need precommit review, etc. | |
176–177 | range-based-for loop, perhaps? | |
265–271 | Hmm - I know when went around a few times on the API a while ago - and perhaps there's good reasons I've since forgotten (sorry :/) but this sort of if/else is something I was hoping to avoid. (by, eg: Having a virtual interface, a TF implementation and a non-TF stub implementation (or fallbacks in the calling code that tested for the absence of an implementation - "if null do the stub/default thing"), and then one function with the #if/else that - and then a single always-compiled function that has a conditional #include and then a "get estimator" function that returns null/default, or the TF implementation if available) - having lots of surface area like this means more chance of failures when someone's building only in one mode or the other. Specifically having different implementations of the same function I think is something best avoided where possible (LLVM has some in the platform APIs, for instance - open a file for Windows, open a file for Linux, etc - but in this case I hope it could be simpler by having only one very small amount of preprocessor conditionalized implementation) |
llvm/lib/Analysis/InlineSizeEstimatorAnalysis.cpp | ||
---|---|---|
265–271 | We did that for the big things - the inline advisor. Here, there's not much of a surface area, and seemed more pragmatic to do it this way. |
llvm/lib/Analysis/InlineSizeEstimatorAnalysis.cpp | ||
---|---|---|
130–133 | yup - thanks, fixed. |
Could replace this with llvm::is_sorted(FunctionFeatures::ImportantInstructionSuccessions); while you're here