And another step towards transforms not introducing inttoptr and/or
ptrtoint casts that weren't there already.
As we've been establishing (see D88788/D88789), if there is a int<->ptr cast,
it basically must stay as-is, we can't do much with it.
I've looked, and the most source of new such casts being introduces,
as far as i can tell, is this transform, which, ironically,
tries to reduce count of casts..
On vanilla llvm test-suite + RawSpeed, @ -O3, this results in
-33.58% less IntToPtrs (19014 -> 12629)
and +76.20% more PtrToInts (18589 -> 32753),
which is an increase of +20.69% in total.
However just on RawSpeed, where i know there are basically
none IntToPtr in the original source code,
this results in -99.27% less IntToPtrs (2724 -> 20)
and +82.92% more PtrToInts (4513 -> 8255).
which is again an increase of 14.34% in total.
To me this does seem like the step in the right direction,
we end up with strictly less IntToPtr, but strictly more PtrToInt,
which seems like a reasonable trade-off.
I'm not presently sure what preparatory fixes are needed before this though.
(Eventually, CastInst::isNoopCast()/CastInst::isEliminableCastPair
should be taught about this, yes)
You might want to be a tad more explicit here, e.g. add "because they have different provenance" or so.