Auto merge of #2332 - rust-lang:slash_slash_at, r=oli-obk
More robust comment parsing
fixes #2170
I haven't ported the entire test suite yet. Once we've done that, I will remove the old parsing system (or in fact, turn them into errors so that accidental usage of old-style comments will be detected)
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.