InstCombine has a `combineLoadToOperationType()` fold, which has the following comment:
// Try to canonicalize loads which are only ever stored to operate over
// integers instead of any other type. We only do this when the loaded type
// is sized and has a size exactly the same as its store size and the store
// size is a legal integer type.
The obvious caveat is, while that does not create `inttoptr` casts immediately,
it does potentially cause creation of `inttoptr` casts afterwards.
I have reduced the PhaseOrdering test from a real code.
It shows, that running SROA after that InstCombine fold, we do end up with `inttoptr` casts,
because we end up having two loads - one of `i8*` and one of `i64`.
I think it's pretty obvious that it is an undesired outcome.
While there are other solutions, i think we can (at least partially?) mitigate/hide
the problem by teaching SROA to try to use the slice's original struct type
instead of immediately falling back to the largest integral use type.