Optional lints for optimizing to maximal efficiency

[JarredAllen]

Inspired by this reddit thread.

I think it would be helpful (and at least one person on reddit agrees with me) if there could be a lint which detects antipatterns which prevent rustc from maximally optimized code (including things like including SIMD instructions, unrolling loops, etc. in the final binary). In the thread and on the page linked from the reddit post, they talk about complicated slice indexing and possible panics as being two common ways for this to happen. There may be other antipatterns we can lint, as well, but none else are mentioned in the thread and I don't know of anything else.

Naturally, this lint should be optional and default to being off, as most sections of code wouldn't need to be that heavily optimized, but this lint could be helpful for people who write code that needs this level of optimization.

[flip1995]

For those lints the perf group exists. If there should be a common (anti)pattern, with an alternative that performs (almost) always better, than a lint for this can be added to this group.

Clippy can't tell how something will be optimized in the end, since LLVM is the compiler backend doing those optimizations. That means automatically/dynamically suggesting code that will be optimized in a better, is not in Clippy's scope (If it were, this lint wouldn't exist in the first place, since it would directly be implemented in rustc as a MIR optimization). This is mainly because Clippy does static code analysis, which require static pre-defined rules for code patterns.

---

My point is: What you're asking for already exists and is enabled by default (clippy::perf). If you have specific ideas for specific patterns that could be linted, feel free to open a "New Lint" issue with an example, and a lint for this could be added in the clippy::perf group. But a magic clippy::optimizations (or similar) lint won't be added, since this is not possible in static code analysis.

[JarredAllen]

I just looked back over my comment and now I can see that there's two different ideas that I muddle together in there:

1. I mention a performance lint (the dynamic slice indexing thing mentioned in the linked post) that'd probably be best to add to clippy::perf as it's own lint, maybe defaulting to allow. I've now made that its own issue, Addressing dynamic slices with unknown size #5605.

2. I start musing about maybe making a category for performance lints that would only make sense to turn on in a critical section of code where small optimizations make a big difference. That'd probably be something good to do once (if) we have enough lints like that to make referring to them as a category useful, but maybe not the best idea right now.

[flip1995]

Thanks for the more specific issue with examples!

For your second point: I also thought about this recently: #5537 (comment) So we could subdivide the pedantic group, so that besides others clippy::pedantic_perf can be enabled separately.