Skip to content

Inline ptr::null(_mut) even in debug builds - #64996

Merged
bors merged 1 commit into
rust-lang:masterfrom
tesuji:inline-ptr-null
Oct 20, 2019
Merged

Inline ptr::null(_mut) even in debug builds#64996
bors merged 1 commit into
rust-lang:masterfrom
tesuji:inline-ptr-null

Conversation

@tesuji

@tesujitesuji commented Oct 2, 2019•
edited
Loading

Copy link
Copy Markdown
Contributor

I think we should treat ptr::null(_mut) as a constant. As It may help reduce code size
in debug build.
See godbolt link: https://godbolt.org/z/b9YMtD

@rust-highfive

rust-highfive commented Oct 2, 2019

Copy link
Copy Markdown
Contributor

r? @Kimundi

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfiverust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 2, 2019
@tesuji

tesuji commented Oct 2, 2019

Copy link
Copy Markdown
ContributorAuthor

r? @eddyb

@rust-highfiverust-highfive assigned eddyb and unassigned KimundiOct 2, 2019
@tesujitesuji closed this Oct 2, 2019
@tesujitesuji reopened this Oct 2, 2019
@eddyb

eddyb commented Oct 2, 2019

Copy link
Copy Markdown
Contributor

LGTM but I'm not sure what our inline policy is, cc @nagisa@rkruppe@gnzlbg

@nagisa

nagisa commented Oct 2, 2019

Copy link
Copy Markdown
Member

I am amused that we do not "just" evaluate ptr::null, as it is a const fn with no arguments…

@nagisa

nagisa commented Oct 2, 2019

Copy link
Copy Markdown
Member

IIRC if there is code that uses #[inline(always)] as opposed to #[inline] the backend automatically toggles opt-level=1, which is what ends up actually making the inline happen. No strong opposition against this change either way.

@hanna-kruppe

hanna-kruppe commented Oct 2, 2019•
edited
Loading

Copy link
Copy Markdown
Contributor

IIRC if there is code that uses #[inline(always)] as opposed to #[inline] the backend automatically toggles opt-level=1, which is what ends up actually making the inline happen. No strong opposition against this change either way.

That would surprise me a lot. I know for sure though that we run the AlwaysInline pass at -O0. This explains why the inlining happens and also why there is a pointless jump in the godbolt output (at -O1 that is cleaned up, presumably by SimplifyCFG).

@nagisa

nagisa commented Oct 2, 2019

Copy link
Copy Markdown
Member

Eeh, my memory failed me then.

@tesujitesuji mentioned this pull request Oct 2, 2019
Merged
@nagisa

nagisa commented Oct 2, 2019

Copy link
Copy Markdown
Member

@oli-obk any ideas why const fns like these aren’t evaluated in-line? Should we do that?

@eddyb

eddyb commented Oct 3, 2019

Copy link
Copy Markdown
Contributor

I think this would fit nicely into my recent suggestion to treat no-argument const fn as an opaque (i.e. we won't peek at the body) const.
(That was in the context of intrinsics like size_of but this seems similar)

Also, does the constant folding MIR pass handle const fn calls at all today?

@tesuji

tesuji commented Oct 6, 2019

Copy link
Copy Markdown
ContributorAuthor

r? @oli-obk

@rust-highfiverust-highfive assigned oli-obk and unassigned eddybOct 6, 2019
@tesujitesuji mentioned this pull request Oct 10, 2019
Merged
@JohnCSimon

JohnCSimon commented Oct 12, 2019

Copy link
Copy Markdown

Ping from triage
@oli-obk can you please review this pr?
cc: @nagisa@rkruppe@gnzlbg

thanks.

tmandry added a commit to tmandry/rust that referenced this pull request Oct 18, 2019
@tmandry
Rollup merge ofrust-lang#65016- lzutao:inline-mem-constfn, r=oli-obk
13e47c8
Always inline `mem::{size_of,align_of}` in debug builds
Those two are const fn and do not have any arguments. Inlining
helps reducing generated code size in debug builds.
See also rust-lang#64996.
tmandry added a commit to tmandry/rust that referenced this pull request Oct 18, 2019
@tmandry
Rollup merge ofrust-lang#65016- lzutao:inline-mem-constfn, r=oli-obk
7167a59
Always inline `mem::{size_of,align_of}` in debug builds
Those two are const fn and do not have any arguments. Inlining
helps reducing generated code size in debug builds.
See also rust-lang#64996.
@oli-obk

oli-obk commented Oct 19, 2019

Copy link
Copy Markdown
Contributor

@bors r+ rollup

Let's do this until const prop can handle function calls

@bors

bors commented Oct 19, 2019

Copy link
Copy Markdown
Collaborator

📌 Commit d0862ec has been approved by oli-obk

@borsbors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 19, 2019
Centril added a commit to Centril/rust that referenced this pull request Oct 19, 2019
@Centril
Rollup merge ofrust-lang#64996- lzutao:inline-ptr-null, r=oli-obk
4d96185
Inline `ptr::null(_mut)` even in debug builds
I think we should treat `ptr::null(_mut)` as a constant. As It may help reduce code size
in debug build.
See godbolt link: https://godbolt.org/z/b9YMtD
@CentrilCentril mentioned this pull request Oct 19, 2019
Closed
Centril added a commit to Centril/rust that referenced this pull request Oct 20, 2019
@Centril
Rollup merge ofrust-lang#64996- lzutao:inline-ptr-null, r=oli-obk
f01ffbc
Inline `ptr::null(_mut)` even in debug builds
I think we should treat `ptr::null(_mut)` as a constant. As It may help reduce code size
in debug build.
See godbolt link: https://godbolt.org/z/b9YMtD
@CentrilCentril mentioned this pull request Oct 20, 2019
Merged
bors added a commit that referenced this pull request Oct 20, 2019
@bors
Auto merge of#65622- Centril:rollup-l8orba7, r=Centril
89e645a
Rollup of 6 pull requests
Successful merges:
- #64996 (Inline `ptr::null(_mut)` even in debug builds)
- #65551 (Avoid realloc in `CString::new`)
- #65593 (add test for calling non-const fn)
- #65595 (move `parse_cfgspecs` to `rustc_interface`)
- #65600 (Remove unneeded `ref` from docs)
- #65602 (Fix plural mistake in emitter.rs)
Failed merges:
r? @ghost
@bors
bors merged commit d0862ec into rust-lang:masterOct 20, 2019
@tesuji
tesuji deleted the inline-ptr-null branch October 20, 2019 18:10
@therealproftherealprof mentioned this pull request Oct 29, 2019
Merged
@sinkuusinkuu mentioned this pull request Oct 30, 2019
Closed
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@oli-obkoli-obk

Labels

S-waiting-on-borsStatus: Waiting on bors to run and complete tests. Bors will change the label on completion.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

9 participants

@tesuji@rust-highfive@eddyb@nagisa@hanna-kruppe@JohnCSimon@oli-obk@bors@Kimundi