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

Inline get_sp_limit, set_sp_limit, get_sp runtime functions #2521

Closed
brson opened this issue Jun 7, 2012 · 1 comment
Closed

Inline get_sp_limit, set_sp_limit, get_sp runtime functions #2521

brson opened this issue Jun 7, 2012 · 1 comment
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows I-slow Issue: Problems and improvements with respect to performance of generated code.

Comments

@brson
Copy link
Contributor

brson commented Jun 7, 2012

These are tiny assembly functions that can account for over 3% in profiles (though set_sp_limit is used less often). Write a benchmark where these are used a lot, rewrite them to be inline C functions containing inline assembly, measure the difference in performance.

@brson
Copy link
Contributor Author

brson commented Jun 14, 2012

Also check_stack_canary

bors added a commit that referenced this issue Mar 25, 2013
As per #2521. Inlining seems to improve performance slightly:

                 Inlined          Not Inlined
    x86:         13.5482            14.4112
    x86_64:      17.4712            18.0696

(Average of 5 runs timed with `time`)

```Rust

fn foo() -> int {
    int::from_str(~"28098").unwrap()
}

fn main() {
    for 1000000.times {
        foo();
        foo();
        foo();
        foo();
        foo();
    }
}
```

All run on:

    Linux 3.2.0-0.bpo.4-amd64 #1 SMP Debian 3.2.35-2~bpo60+1 x86_64 GNU/Linux

The MIPS and ARM bits I didn't inline since I'm not as familiar with them and I also can't test them. All green on try.
@luqmana luqmana closed this as completed Apr 25, 2013
flip1995 added a commit to flip1995/rust that referenced this issue Dec 6, 2020
Add Collapsible match lint

changelog: Add collapsible_match lint

Closes rust-lang#1252
Closes rust-lang#2521

This lint finds nested `match` or `if let` patterns that can be squashed together. It is designed to be very conservative to only find cases where merging the patterns would most likely reduce cognitive complexity.

Example:

```rust
match result {
    Ok(opt) => match opt {
        Some(x) => x,
        _ => return,
    }
    _ => return,
}
```
to
```rust
match result {
    Ok(Some(x)) => x,
    _ => return,
}
```

These criteria must be met for the lint to fire:

* The inner match has exactly 2 branches.
* Both the outer and inner match have a "wild" branch like `_ => ..`. There is a special case for `None => ..` to also be considered "wild-like".
* The contents of the wild branches are identical.
* The binding which "links" the matches is never used elsewhere.

Thanks to the hir, `if let`'s are easily included with this lint since they are desugared into equivalent `match`'es.

I think this would fit into the style category, but I would also understand changing it to pedantic.
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
Bump UI test dependency

This gives us the new diff renderer as well as the ability to run tests without parallelism if we'd want to.
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
Users can now specify a command that will be run to parse the result of
a single suite x variant run, as an alternative to specifying a python
module that is checked into the Kani codebase. This allows for parsers
to be maintained outside the Kani codebase.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows I-slow Issue: Problems and improvements with respect to performance of generated code.
Projects
None yet
Development

No branches or pull requests

2 participants