Remove non-consecutive stores from candidate search as they can never
be merged and may prevent us from finding subsequent merges.
Details
Details
Diff Detail
Diff Detail
- Build Status
Buildable 5561 Build 5561: arc lint + arc unit
Event Timeline
Comment Actions
The limitations of store merging aren't clear to me. Can you add a code comment about why this is necessary? I would have assumed that we'd merge the later consecutive stores when visiting them because we visited them first.
Also, it would be better to add a more obvious test case. I think this should work as an x86 test:
; Don't let a non-consecutive store thwart merging of the last two.
define void @almost_consecutive_stores(i8* %p) {
store i8 0, i8* %p
%p1 = getelementptr i8, i8* %p, i64 42
store i8 1, i8* %p1
%p2 = getelementptr i8, i8* %p, i64 2
store i8 2, i8* %p2
%p3 = getelementptr i8, i8* %p, i64 3
store i8 3, i8* %p3
ret void
}If that's correct, can you add that test as an NFC change ahead of this patch, so we just see the diff from your patch? Thanks.
comma after "However"