[SROA] Handle more alignment corner cases rather than asserting #256
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The existing downstream alignment handling stopped merging in
unsplittable slices if they would be unaligned. However, in this case,
we're already covering at least part of such slices with the current
partition, and that partition contains unsplittable slices, so we cannot
just stop early. This had the result that, if we ever hit that case, the
next call to advance would fail the assertion that BeginOffset didn't go
backwards.
The current single-pass implementation from upstream is complicated to
reason about, mixing correctness properties (handling of unsplittable
slices and, in our extended code, alignment) with heuristics on where to
split within those constraints. It's also done as a single pass which,
whilst workable without alignment constraints, is not in general
possible once alignment is required (at least not unless you want to
introduce the concept of head padding).
This new implementation introduces AllocaSplitCandidates, which
pre-scans the slices to determine a set of possible split points, and
AllocaSplitRequester, which takes a heuristic-based request from
AllocaSlices::partition_iterator and returns a legal split point for it
to use. It also allows multiple queries before committing to one, so the
split point can be advanced and walked back as more slices are scanned.
The intent is that, despite the new implementation, the returned
partitions are unchanged for all cases that weren't previously
incorrectly-handled. In particular, since slices only ever have
alignment other than 1 for CHERI, non-CHERI should not see any changes.