While ptrtoint can and should be treated transparently by the passes,
inttoptr is a black box. SCEV does not, should not, and will not model it.
But that means, given two identical, but separate inttoptr instructions,
SROA won't be able to tell that they have the same pointer value.
Likewise for pointers with the same integer base but different pointee types.
Currently, InstCombine already ensures that inttoptr/ptrtoint don't change
the integer width, but it is performed separately before/after.
Let's do the same for target pointee type for inttoptr.
I.e. if it's not an i8*, reconstruct inttoptr + emit bitcast.
And let's rely on EarlyCSE to be able to CSE them,
thus making them somewhat less of a hurdle for SROA/etc.
Notably, i don't think we should do the same for ptrtoint.
Now, this causes some test regressions.
I've fixed SROA issue (D99051), and one InstCombine issue
(p2i (?bitcast (ins (?bitcast (i2p Vec)), Scalar, Index)) --> ins Vec, (p2i Scalar), Index),
but there may be few more in tests, i'll comment on them.
I'm not sure off-hand about what to do with them.
clang-tidy: warning: invalid case style for function 'm_BitCastOrSelf' [readability-identifier-naming]
not useful