(it was introduced in https://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html)
This canonicalization seems dubious.
Most importantly, while it does not create inttoptr casts by itself,
it may cause them to appear later, see e.g. D88788.
I think it's pretty obvious that it is an undesirable outcome,
by now we've established that seemingly no-op inttoptr/ptrtoint casts
are not no-op, and are no longer eager to look past them.
Which e.g. means that given
%a = load i32 %b = inttoptr %a %c = inttoptr %a
we likely won't be able to tell that %b and %c is the same thing.
We could of course try to cleanup the IR afterwards, by enhancing
the cast-of-load transform to deal with non-single-use loads,
and i even tried that already in D75505, as it was rightfully
pointed out, that is very much not compile-time free:
https://llvm-compile-time-tracker.com/compare.php?from=871d03a6751e0f82e210c80a881ef357c5633a26&to=782be5b99377b62e998e4157ddede0fa296664b5&stat=instructions
Thusly, i'd propose to simply not perform such a canonicalization.
The original motivational RFC does not state what larger problem that canonicalization
was trying to solve, so i'm not sure how this plays out in the larger picture.
Does anyone have any thoughts?