tweak inttoptr allocation behavior #795
Conversation
|
Besides being picky about the residue computation. I was thinking about having the option to disable adding slack just from a performance POV. But I suppose that's a whole discussion for other day |
Indeed. And that discussion would start with some benchmarks showing that adding slack even makes a measurable performance impact. Given how slow Miri is, I would be very surprised if it did. ;) |
|
|
||
| let base_addr = match alloc.extra.intptrcast.base_addr.get() { | ||
| Some(base_addr) => base_addr, | ||
| None => { | ||
| // This allocation does not have a base address yet, pick one. | ||
| let base_addr = Self::align_addr(global_state.next_base_addr, alloc.align.bytes()); | ||
| global_state.next_base_addr = base_addr + alloc.bytes.len() as u64; | ||
| // Leave some space to the previous allocation, to give it some chance to be less aligned. |
There was a problem hiding this comment.
why random and not maximally unaligned?
There was a problem hiding this comment.
That would be deterministic. Then I would be sure, for example, that by adding 2 to the base address of a 2-aligned allocation, I would get something 4-aligned.
|
☔ The latest upstream changes (presumably #802) made this pull request unmergeable. Please resolve the merge conflicts. |
- Make `align_addr` not offset by `align` for no reason. - Add some random slack between allocations to give them the chance to not be aligned.
|
@bors r+ |
|
📌 Commit 0bb50ad has been approved by |
tweak inttoptr allocation behavior - Make `align_addr` not offset by `align` for no reason. - Add some random slack between allocations to give them the chance to not be aligned. Cc @christianpoveda Fixes #791
|
☀️ Test successful - checks-travis, status-appveyor |
align_addrnot offset byalignfor no reason.Cc @christianpoveda
Fixes #791