This patch adds support for constant inttoptr/ptrtoint expressions to
unblock the running of csmith-generated programs.
The test doesn't cover all the behaviours, as they have been tested by
previous tests.
This patch treats constant inttoptr/ptrtoint expressions as if they are
executed just before the user. However, since ptrtoint exposes the
pointer provenance and inttoptr relies on the current set of exposed
provenances, it is incorrect. Imagine that we have an inttoptr in a gep
instruction and a ptrtoint in an add instruction. They can be freely
DCEd/reordered. In addition, the behaviour also depends on the
initialization order of globals. That is terrible. Nikita's proposal
also mentioned this issue but left it as an open question:
https://hackmd.io/@nikic/SJBt4mFCll#Constant-expressions
From my perspective, constant expressions are allowed to execute at any
point in the program (before their users). Moving ptrtoint forward or
inttoptr backward will not make the program more undefined. So we can
evaluate all constant expressions before the program entry (i.e., all
globals involved with ptrtoint will be exposed at the start). The only
remaining concern is the use of `ConstantExpr::getAsInstruction`,
because it will convert CEs back into instruction sequences :(
Yingwei Zheng
89c6fa58bb