Folding inttoptr(ptrtoint p) -> p has been known as a source of miscompilation (http://llvm.org/pr34548)
because it swaps the object that some pointer is based-on.
Recently I've been playing with CastInst::isEliminableCastPair to see how removal of it
affects performance, and got very nice results.
On x86-64, compiling single amalgamated file benchmarks (bzip2, gzip, oggenc, ph7, sqlite3, gcc)[1, 2, 3]
didn't show a single difference in assembly even after the folding is removed.
I guess this is highly related to the recent efforts (D88788, D88789, D88979) in reducing the number of
inttoptr casts unnecessarily generated by middle-end transformations.
The int->ptr casts used in the source programs are either
(1) int->ptr casts of a constant, e.g. (int*)-1
(2) manipulating bits using constants, e.g. (int*)((intptr_t)x | 0x3
The first one cannot gain benefit from inttoptr(ptrtoint p) -> p folding anyway.
The second one may gain benefit in theory, but for the 6 benchmarks it didn't. Also, there are possible cases where folding is allowed, and we can suggest using llvm.ptrmask as well for better performance.
For larger benchmark, I chose LLVM (as suggested by @nlopes).
Compiling LLVM with/without this folding showed quite a few differences in assembly, however.
But they are still mostly from inttoptrs generated by the optimizations.
This patch fixes LLVM by using load/store i8* (which is char* in C/C++) instead if !tbaa_struct
says the element had a character type: https://godbolt.org/z/PTaM51fKo
This patch reduces the number of different assembly files from 1255 to 845 (-32%).
This also reduces the total number of inttoptrs after -O3 significantly for some files.