During store merge we construct a sorted list of consecutive store candidates and consider
subsequences for merging into a single store. For each subsequence we check if the stored
value type is legal the merged store would have valid and fast and if the constructed value
to be stored is valid. The only properties that affect this check between subsequences is the
size of the subsequence, the alignment of the first store, the alignment of the stored load
value (when merging stores-of-loads), and whether the merged value is a constant zero.
If we do not find a viable mergeable subsequence starting from the first store of length N,
we know that a subsequence starting at a later store of length N will also fail unless the
new store's alignment, the new load's alignment (if we're merging store-of-loads), or we've
dropped stores of nonzero value and could construct a merged stores of zero (for merging
constants).
As a result if we fail to find a valid subsequence starting from the first store we can safely
skip considering subsequences that start with subsequent stores unless one of the above
properties is true. This significantly (2x) improves compile time in some pathological cases.