Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change #[inline(always)] to #[inline(force)] #6987

Closed
wants to merge 5 commits into from

Conversation

Aatch
Copy link
Contributor

@Aatch Aatch commented Jun 7, 2013

This pull request changes #[inline(always)] to #[inline(force)]. The old version now emits a warning, but still maintains the always_inline behaviour.

The libraries all have been changed, so no warning there. I also de-forced a lot of functions/methods, though none have had the inline attribute removed completely. I also added #[inline] to several functions that seemed like good candidates.

I haven't checked to see if this changes the compilation time, I don't think it will.

@bstrie
Copy link
Contributor

bstrie commented Jun 7, 2013

What criteria are you using to determine when #[inline(always)] should be replaced by just #[inline]? Have you done any measurements on the effect that this change has on compile time and binary size?

@bstrie
Copy link
Contributor

bstrie commented Jun 7, 2013

I do sort of like how "force" sounds more dire than "always", to imply that this is a tool that you should use with caution. But I'd like a dev to determine if this naming change is desirable.

@glaebhoerl
Copy link
Contributor

I like it too. A related possibility would be to rename #[inline] to #[inline(please)], to bring it in line syntactically and make the meaning more obvious.

@Aatch
Copy link
Contributor Author

Aatch commented Jun 7, 2013

@bstrie my criteria was based on whether it should be forced, rather than whether it shouldn't. Most functions that implemented the for protocol were forced, as LLVM has issues there. The majority of operator overloads are forced, a couple of functions that had a comment saying that they should be forced. Everything else is marked with just inline.

The major reason for many of the inlined functions is to get it to output the AST for cross-crate inlining.

LLVM will potentially inline any function if it thinks it will help.

@Aatch
Copy link
Contributor Author

Aatch commented Jun 7, 2013

@glehel technically that does work as expected, as if we don't recognise the contents of the inline, we just treat it as a regular inline hint.

@brson
Copy link
Contributor

brson commented Jun 8, 2013

Why are you changing 'always' to 'force'? #[inline(never)] and #[inline(always)] have an obvious symmetry that 'force' lacks.

@Aatch
Copy link
Contributor Author

Aatch commented Jun 8, 2013

@brson as @bstrie pointed out, 'force' sounds more "dire". The idea is that 'force' actually better describes what your are doing. I mean, sure they mean the same thing, but you are actually forcing the compiler to inline the function. 'always' still seems like a request, it's too off-hand with respect to what you are asking. 'always' also suggests that the developer knows what they are doing, and when it comes to this kind of optimization. They normally don't.

Most tools that have a 'force' option, have it as a way to override some default safety check, be it pushing a diverged branch in git, or removing read-only files with rm. They use 'force' because it changes the default sensible behaviour at the expense of the tool throwing it's hands up and saying "Ok, ok, you're the boss, but don't come crying to me when things go sour". Inlining is a tool, and most of the time, a normal #[inline] will suffice. Both #[inline(force)] and #[inline(never)] are assertions that you know what you are doing.

Lastly, people have abused the feature, marking rather large functions as #[inline(always)], presumably out of an almost cargo-cult attitude regarding performance. As I understand it, this stems from it's usage on iterator functions in vec where the generated code played havoc with LLVM's inlining heuristics, resulting performance issues.

tl;dr: #[inline(always)] is too nice, #[inline(force)] sounds scary. Maybe this will make people think about what they are doing.

(P.S. I will rebase if/when this gets provisionally approved)

@Aatch
Copy link
Contributor Author

Aatch commented Jun 11, 2013

Can I get an update here? The longer this waits the more painfully it's going to be to rebase.

@bstrie
Copy link
Contributor

bstrie commented Jun 11, 2013

@Aatch Try bringing it up on the mailing list or ask that it be discussed in the meeting today.

@brson
Copy link
Contributor

brson commented Jun 13, 2013

I don't favor the change to force per my previous comment, though I do like removing inline(always) from most of its current uses. My preference is to keep the old name while removing the uses of inline(always).

@nikomatsakis
Copy link
Contributor

I prefer using the same names that LLVM uses.

@pnkfelix
Copy link
Member

This is probably implicit in Niko's remark: LLVM uses the names "always" and "never". (At least, that's what I garner from the docs for InlineCost.h)

@graydon graydon closed this Jun 13, 2013
flip1995 pushed a commit to flip1995/rust that referenced this pull request Apr 8, 2021
Don't trigger `same_item_push` if the vec is used in the loop body

fixes rust-lang#6987
changelog: `same_item_push`: Don't trigger if the `vec` is used in the loop body
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants