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

Rollup of 12 pull requests #39565

Closed
wants to merge 32 commits into from
Closed

Rollup of 12 pull requests #39565

wants to merge 32 commits into from

Conversation

ishitatsuyuki and others added 30 commits February 3, 2017 16:15
Only set the flags if they differ from what the OS reported, use
`FIONBIO` to atomically set the non-blocking IO flag on Linux.
We introduced the unadjusted ABI to work around wrong
(buggy) ABI expectations by LLVM on Windows [1].
Therefore, it should be solely used on Windows and not
on other platforms, like right now is the case.

[1]: see this comment for details rust-lang#38482 (comment)
Instead of directly creating a 'DIGlobalVariable', we now have to create
a 'DIGlobalVariableExpression' which itself contains a reference to a
'DIGlobalVariable'.

This is a straightforward change.

In the future, we should rename 'DIGlobalVariable' in the FFI
bindings, assuming we will only refer to 'DIGlobalVariableExpression'
and not 'DIGlobalVariable'.
First, get rid of some bound checks.

Second, instead of comparing by ternary `compare` function, use a binary
function testing whether an element is less than some other element.
This apparently makes it easier for the compiler to reason about the
code.

Benchmark:

```
name                                        before ns/iter        after ns/iter         diff ns/iter   diff %
slice::bench::sort_large_ascending          8,969 (8919 MB/s)     7,410 (10796 MB/s)          -1,559  -17.38%
slice::bench::sort_large_big_ascending      355,640 (3599 MB/s)   359,137 (3564 MB/s)          3,497    0.98%
slice::bench::sort_large_big_descending     427,112 (2996 MB/s)   424,721 (3013 MB/s)         -2,391   -0.56%
slice::bench::sort_large_big_random         2,207,799 (579 MB/s)  2,138,804 (598 MB/s)       -68,995   -3.13%
slice::bench::sort_large_descending         13,694 (5841 MB/s)    13,514 (5919 MB/s)            -180   -1.31%
slice::bench::sort_large_mostly_ascending   239,697 (333 MB/s)    203,542 (393 MB/s)         -36,155  -15.08%
slice::bench::sort_large_mostly_descending  270,102 (296 MB/s)    234,263 (341 MB/s)         -35,839  -13.27%
slice::bench::sort_large_random             513,406 (155 MB/s)    470,084 (170 MB/s)         -43,322   -8.44%
slice::bench::sort_large_random_expensive   23,650,321 (3 MB/s)   23,675,098 (3 MB/s)         24,777    0.10%
slice::bench::sort_medium_ascending         143 (5594 MB/s)       132 (6060 MB/s)                -11   -7.69%
slice::bench::sort_medium_descending        197 (4060 MB/s)       188 (4255 MB/s)                 -9   -4.57%
slice::bench::sort_medium_random            3,358 (238 MB/s)      3,271 (244 MB/s)               -87   -2.59%
slice::bench::sort_small_ascending          32 (2500 MB/s)        32 (2500 MB/s)                   0    0.00%
slice::bench::sort_small_big_ascending      97 (13195 MB/s)       97 (13195 MB/s)                  0    0.00%
slice::bench::sort_small_big_descending     247 (5182 MB/s)       249 (5140 MB/s)                  2    0.81%
slice::bench::sort_small_big_random         502 (2549 MB/s)       498 (2570 MB/s)                 -4   -0.80%
slice::bench::sort_small_descending         55 (1454 MB/s)        61 (1311 MB/s)                   6   10.91%
slice::bench::sort_small_random             358 (223 MB/s)        356 (224 MB/s)                  -2   -0.56%
```
Before, the `count` would be copied into the closure and could
potentially be optimized way. This change ensures it's borrowed by
closure and finally consumed by `test::black_box`.
issue-32829.rs was introduced in f6a243d (2 June 2016), but
issue32829.rs was introduced in 94a0552 (9 May 2016). Weird! Let's
combine them for the best of both worlds.
…gisa

Don't use "unadjusted" ABI on non windows platforms

We introduced the unadjusted ABI to work around wrong
(buggy) ABI expectations by LLVM on Windows [1].
Therefore, it should be solely used on Windows and not
on other platforms, like right now is the case.

[1]: see this comment for details rust-lang#38482 (comment)
liballoc_jemalloc: fix linking with system library

Fix rust-lang#39215
…eebsd, r=alexcrichton

Support aarch64-unknown-freebsd
…hton

Extract libcore benchmarks to a separate folder

Fix rust-lang#39484

r? @alexcrichton since you seem to know about this :)

Thanks!
…chton

Use less syscalls in `FileDesc::set_{nonblocking,cloexec}`

Only set the flags if they differ from what the OS reported, use
`FIONBIO` to atomically set the non-blocking IO flag on Linux.
…alexcrichton

[LLVM 4.0] Support a debug info API change for LLVM 4.0

Instead of directly creating a `DIGlobalVariable`, we now have to create
a `DIGlobalVariableExpression` which itself contains a reference to a
'DIGlobalVariable'.

This is a straightforward change.

In the future, we should rename `DIGlobalVariable` in the FFI
bindings, assuming we will only refer to `DIGlobalVariableExpression`
and not `DIGlobalVariable`.
ignore more gdb versions with buggy rust support

This extends the versions of gdb which were ignored in rust-lang#39039. While just ignoring gdb versions up to 7.12.1 would have been sufficient for now, I believe (after consulting https://sourceware.org/gdb/wiki/Internals%20Versions)  that ignoring versions up to 7.12.9 will prevent the tests failing again for 7.12.2, etc. while still running all tests for the development versions of gdb (which will be >= 7.12.10 as far as I can tell).

This should fix rust-lang#39522.

cc @Manishearth, @michaelwoerister, rust-lang#38948
…alexcrichton

Slightly optimize slice::sort

First, get rid of some bound checks.

Second, instead of comparing by ternary `compare` function, use a binary function testing whether an element is less than some other element. This apparently makes it easier for the compiler to reason about the code. I've noticed the same effect with [pdqsort](https://github.com/stjepang/pdqsort) crate.

Benchmark:

```
name                                        before ns/iter        after ns/iter         diff ns/iter   diff %
slice::bench::sort_large_ascending          8,969 (8919 MB/s)     7,410 (10796 MB/s)          -1,559  -17.38%
slice::bench::sort_large_big_ascending      355,640 (3599 MB/s)   359,137 (3564 MB/s)          3,497    0.98%
slice::bench::sort_large_big_descending     427,112 (2996 MB/s)   424,721 (3013 MB/s)         -2,391   -0.56%
slice::bench::sort_large_big_random         2,207,799 (579 MB/s)  2,138,804 (598 MB/s)       -68,995   -3.13%
slice::bench::sort_large_descending         13,694 (5841 MB/s)    13,514 (5919 MB/s)            -180   -1.31%
slice::bench::sort_large_mostly_ascending   239,697 (333 MB/s)    203,542 (393 MB/s)         -36,155  -15.08%
slice::bench::sort_large_mostly_descending  270,102 (296 MB/s)    234,263 (341 MB/s)         -35,839  -13.27%
slice::bench::sort_large_random             513,406 (155 MB/s)    470,084 (170 MB/s)         -43,322   -8.44%
slice::bench::sort_large_random_expensive   23,650,321 (3 MB/s)   23,675,098 (3 MB/s)         24,777    0.10%
slice::bench::sort_medium_ascending         143 (5594 MB/s)       132 (6060 MB/s)                -11   -7.69%
slice::bench::sort_medium_descending        197 (4060 MB/s)       188 (4255 MB/s)                 -9   -4.57%
slice::bench::sort_medium_random            3,358 (238 MB/s)      3,271 (244 MB/s)               -87   -2.59%
slice::bench::sort_small_ascending          32 (2500 MB/s)        32 (2500 MB/s)                   0    0.00%
slice::bench::sort_small_big_ascending      97 (13195 MB/s)       97 (13195 MB/s)                  0    0.00%
slice::bench::sort_small_big_descending     247 (5182 MB/s)       249 (5140 MB/s)                  2    0.81%
slice::bench::sort_small_big_random         502 (2549 MB/s)       498 (2570 MB/s)                 -4   -0.80%
slice::bench::sort_small_descending         55 (1454 MB/s)        61 (1311 MB/s)                   6   10.91%
slice::bench::sort_small_random             358 (223 MB/s)        356 (224 MB/s)                  -2   -0.56%
```
…oogaloo, r=petrochenkov

continue to prefer hyphens in test files named after issue numbers

a [followup](rust-lang#38473 (comment)) to rust-lang#38473

(The files in `auxillary/` directories have an excuse, as they get used as crates/modules, for which snake_case names make more sense.)
@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @sfackler (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@frewsxcv
Copy link
Member Author

frewsxcv commented Feb 5, 2017

@bors r+ p=50

@bors
Copy link
Contributor

bors commented Feb 5, 2017

📌 Commit be95d13 has been approved by frewsxcv

@frewsxcv frewsxcv closed this Feb 5, 2017
@frewsxcv frewsxcv deleted the rollup branch February 5, 2017 17:41
@Centril Centril added the rollup A PR which is a rollup label Oct 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup
Projects
None yet
Development

Successfully merging this pull request may close these issues.