On 30/05/13 16:39, Mikhail Zabaluev wrote:
Why even have the option? The programmer almost never has better
information than the compiler to decide whether a function could be
beneficially inlined at each particular call site. And as we see with
the Rust code base itself, this has a great potential of being
unwittingly abused. Look, a "make my function run fast" directive!
Apparently it's required to guarantee that LLVM inlines the closure in
for loops (e.g. uint::range).
Plain #[inline] has a declarative value, though. I haven't looked into
what the compiler does, but I guess #[inline] can instruct it to emit
metadata for inlining a public function at the call site, rather than
just shipping a symbol in the crate.
This is correct, as far as I understand; the AST of a function has to be
written to the crate for cross-crate inlining (so that it is accessible
to Rust/LLVM on the next compilations), and this is only written for
#[inline(always)] and #[inline]. However, #[inline] isn't just doing
this, it also sets the inline hint for LLVM, which makes it inline more
eagerly than the default.
(I've got an old PR[1] that adds #[inline(maybe)], which is the same as
#[inline] but doesn't set the hint, i.e. it allows cross-crate inlining
by writing the AST to the crate, but gives LLVM full control of when and
where to do it. However, it seems that people aren't super keen on it.)
Huon
[1]: https://github.com/mozilla/rust/pull/6616
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
