Adds support for the operations added in https://github.com/rust-lang/rust/pull/96935.
I made the pointer-binops always return the provenance of the *left* argument; `@thomcc` I hope that is what you intended. I have honestly no idea if it has anything to do with what LLVM does...
I also simplified our pointer comparison code while I was at it -- now that *all* comparison operators support wide pointers, we can unify those branches.
This is quite ad-hoc but better than nothing IMO.
I have also deleted the old `benches` folder. Some of these tests have UB :joy: and the rest doesn't seem very useful to benchmark the things that are slow about Miri today.
These are the sources of `@solson's` original report, I think. They will remain available in the git history, but I don't think there is much point in still carrying them around on master. The readme links to their rendered PDFs:
- https://solson.me/miri-slides.pdf
- https://solson.me/miri-report.pdf
Following [this recommendation](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/.22target.22.20directory.20in.20rustc.20tree.3F/near/288428273)
Cc https://github.com/rust-lang/rustc-dev-guide/pull/1384
Auto merge of #2319 - RalfJung:dont-touch-vtables, r=RalfJung
fix retagging of vtable ptrs
Fixes a problem reported by `@saethlin` on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/269128-miri/topic/Stacked.20Borrows.20field.20retagging/near/288040048).
Auto merge of #1935 - saethlin:optimize-sb, r=RalfJung
Optimizing Stacked Borrows (part 1?): Cache locations of Tags in a Borrow Stack
Before this PR, a profile of Miri under almost any workload points quite squarely at these regions of code as being incredibly hot (each being ~40% of cycles):
This code is one of at least three reasons that stacked borrows analysis is super-linear: These are both linear in the number of borrows in the stack and they are positioned along the most commonly-taken paths.
I'm addressing the first loop (which is in `Stack::find_granting`) by adding a very very simple sort of LRU cache implemented on a `VecDeque`, which maps recently-looked-up tags to their position in the stack. For `Untagged` access we fall back to the same sort of linear search. But as far as I can tell there are never enough `Untagged` items to be significant.
I'm addressing the second loop by keeping track of the region of stack where there could be items granting `Permission::Unique`. This optimization is incredibly effective because `Read` access tends to dominate and many trips through this code path now skip the loop entirely.
These optimizations result in pretty enormous improvements:
Without raw pointer tagging, `mse` 34.5s -> 2.4s, `serde1` 5.6s -> 3.6s
With raw pointer tagging, `mse` 35.3s -> 2.4s, `serde1` 5.7s -> 3.6s
And there is hardly any impact on memory usage:
Memory usage on `mse` 844 MB -> 848 MB, `serde1` 184 MB -> 184 MB (jitter on these is a few MB).
Auto merge of #2316 - domenicquirl:readme-track-tag, r=RalfJung
Clarify the effect of the `-Zmiri-track-pointer-tag` flag in the README
Edit the README to explicitly say that the `-Zmiri-track-pointer-tag` flag also tracks the creation of tags, not just when they are popped/invalidated.
Related to https://github.com/rust-lang/miri/pull/2308 / https://github.com/Manishearth/triomphe/issues/38.
Auto merge of #2317 - RalfJung:this-is-not-a-std-test-suite, r=RalfJung
move arc_drop test to miri-test-libstd
That's where we have a bunch of slow and unlikely-to-regress tests already. Miri's test suite should primarily test Miri; we sometimes add libstd tests when they are cheap and/or exercise interesting code paths in Miri. https://github.com/rust-lang/miri/pull/2248 already ensures that we allow code like `Arc` with more direct tests.
Auto merge of #2304 - LegNeato:shim-fstat64-mac, r=oli-obk
Support (stat/fstat/lstat)64 on macos
"In order to accommodate advanced capabilities of newer file systems,
the struct stat, struct statfs, and struct dirent data structures
were updated in Mac OSX 10.5."
"TRANSITIONAL DESCRIPTION (NOW DEPRECATED)
The fstat64, lstat64 and stat64 routines are equivalent to their
corresponding non-64-suffixed routine, when 64-bit inodes are in
effect. They were added before there was support for the symbol
variants, and so are now deprecated. Instead of using these, set
the _DARWIN_USE_64_BIT_INODE macro before including header files to
force 64-bit inode support. The stat64 structure used by these deprecated routines is the same
as the stat structure when 64-bit inodes are in effect (see above)."
"HISTORY
An lstat() function call appeared in 4.2BSD. The stat64(),
fstat64(), and lstat64() system calls first appeared in Mac OS X
10.5 (Leopard) and are now deprecated in favor of the corresponding
symbol variants. The fstatat() system call appeared in OS X 10.10"
"In order to accommodate advanced capabilities of newer file systems,
the struct stat, struct statfs, and struct dirent data structures
were updated in Mac OSX 10.5."
"TRANSITIONAL DESCRIPTION (NOW DEPRECATED)
The fstat64, lstat64 and stat64 routines are equivalent to their
corresponding non-64-suffixed routine, when 64-bit inodes are in
effect. They were added before there was support for the symbol
variants, and so are now deprecated. Instead of using these, set
the _DARWIN_USE_64_BIT_INODE macro before including header files to
force 64-bit inode support.
The stat64 structure used by these deprecated routines is the same
as the stat structure when 64-bit inodes are in effect (see above)."
"HISTORY
An lstat() function call appeared in 4.2BSD. The stat64(),
fstat64(), and lstat64() system calls first appeared in Mac OS X
10.5 (Leopard) and are now deprecated in favor of the corresponding
symbol variants. The fstatat() system call appeared in OS X 10.10"
Auto merge of #2302 - RalfJung:datarace, r=RalfJung
avoid copying thread manager state in data race detector
When doing https://github.com/rust-lang/miri/pull/2047 I did not realize that there is some redundant state here that we can now remove from the data race detector.
Also this removes the vector clocks from the data race errors since those don't really help diagnose the problem.
Ben Kimock [Wed, 8 Dec 2021 03:05:13 +0000 (22:05 -0500)]
Cache lookups into the borrow stack
This adds a very simple LRU-like cache which stores the locations of
often-used tags. While the implementation is very simple, the cache hit
rate is incredible at ~99.9% on most programs, and often the element at
position 0 in the cache has a hit rate of 90%. So the sub-optimality of
this cache basicaly vanishes into the noise in a profile.
Additionally, we keep a range which denotes where there might be an item
granting Unique permission in the stack, so that when we invalidate
Uniques we do not need to scan much of the stack, and often scan nothing
at all.
Auto merge of #2296 - RalfJung:miri-script, r=RalfJung
./miri improvements
I have needed to run something with many different seeds often enough that I would like an easier way to do it. ;) So now we have `./miri many-seeds`.
Also I made the script less dependent on the working directory, so calling it from a different directory should work properly now even if that other directory does not have the same rustup override as the one where Miri lives.
projects / rust.git / log