The current integer widening does not support rewriting partial split spice in rewriteIntegerStore (and rewriteIntegerLoad).
This patch adds explicit check for this in isIntegerWideningViableForSlice.
Before r322533, splitting is allowed only for the whole-alloca slice and hence the above case is implicitly rejected by another check if (DL.getTypeStoreSize(ValueTy) > Size) because whole-alloca slice is larger than the partition.
By adding this case, there was no visible difference in the number of widening happened during the bootstrap test.
Instead of doing this implicit signed-unsigned conversion, could you explicitly check "S.beginOffset() < AllocBeginOffset"? It's confusing to have to worry about overflow. (Granted, I don't think the overflowing case is likely to show up in practice, but there isn't anything preventing it.)