Function attributes for optimization outside source files

several attributes (primarily #[inline] and #[cold]) are merely directives for how the program should be optimized, with no effect on the actual semantics of the code.

i believe it would be helpful to be able to specify these attributes in an external file, instead of directly within the code.

this would have several advantages:

  1. these files would be unable to affect program behavior, so they would be less crucial to review (currently someone could submit a PR adding 200 #[inline] annotations and one line that introduces an intentional backdoor)
  2. they could be specified for any crate, not just the current one. this is useful since a frequently used function in one project may only be used for one obscure edge case in another.
  3. for high-performance rapidly iterating projects, this would mean less source code churn and thus less merge conflicts.
  4. all of these combined would mean that automatically generating these attributes (eg. via profiling) would be more viable
1 Like

Adding these inline attributes poses a potential security risk, depending on the context. Time-based side channel attacks are sensitive to optimization, including inlining.

Therefore, this separation offers no advantage since all code modifications should undergo appropriate review.

2 Likes

Wouldn't PGO already handle this by affecting the inlining decisions on the next build? There is also LLVM Bolt for further optimisation of function placement.

It also seems hard to keep such out of band data in sync, what should happen when the function is renamed and the external file refers to a non-existent function.

Perhaps being able to mark call sites as inline (by an inband attribute) would solve point 2.

5 Likes

unless i'm mistaken, that type of attack only applies to applications that handle sensitive data, like a password manager. additionally, such applications should be using fixed-time cryptographic comparison operations, and if those rely on not being inlined for correctness, they should be annotated as #[inline(never)].

also, ease of review is only one of the listed advantages, the other being the ability to tweak the optimization behavior of dependencies.

1 Like

really, this is just an extention of profile guided optimization, which rustc already supports.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.