Conversation
|
r? @zackmdavis (rust_highfive has picked a reviewer for you, use r? to override) |
|
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
RalfJung
left a comment
There was a problem hiding this comment.
I expect that the miri submodule update will get messy because we don't know in which order our PRs will land. As long as we have so many miri-breaking PRs in flight, I think it is better to do the submodule updates separately.
| ) -> EvalResult<'tcx> { | ||
| // Empty accesses don't need to be valid pointers, but they should still be non-NULL | ||
| let align = Align::from_bytes(1, 1).unwrap(); | ||
| if size.bytes() == 0 { |
There was a problem hiding this comment.
Now we check for emptiness twice. I think it should be fine to say that all the methods on an Allocation require an in-bounds ptr, even for size 0 -- then we'd have no special handling for size 0 here at all. All the handling would be in memory.rs where we need it anyway to handle integer pointers.
|
before removing the size==0 checks I was seeing nice perf improvements. Lets see if this was me failing to run perfruns properly. @bors try |
|
@rust-timer build 80add95 |
|
Success: Queued 80add95 with parent 3476ac0, comparison URL. |
|
Do we also want to find a new home for |
pointer.rs ? |
|
What would be in there? Sounds reasonable. |
|
r=me if you remove the miri update and perf looks good |
|
☔ The latest upstream changes (presumably #55347) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Finished benchmarking try commit 80add95 |
|
Oh yes! improvements up to 6% across the board. Not fetching those allocations 4x for 4 checks does have an effect. |
fba8adc to
a8b9eec
Compare
|
@bors r=RalfJung |
|
📌 Commit a8b9eec4d2ca87ea45edb4f53682394eca7c893d has been approved by |
…rough `.get(alloc_id)`
This reverts commit d50e401.
880ba86 to
0aa2aa8
Compare
|
I am unable to reproduce on x86 linux. I also don't see how these changes could cause changes in the emitted machine code. It's just a refactoring moving functions between modules. I could do this PR in steps by splitting it into smaller PRs |
|
I don't have any better idea either. Maybe reduce this one to the most bitrotty "moving stuff around" part ( |
|
☔ The latest upstream changes (presumably #55316) made this pull request unmergeable. Please resolve the merge conflicts. |
|
blocked on #55674 |
|
closing in favour of #55915 |
No description provided.