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"