analyze: add pointee_type analysis #1029
Conversation
| #[derive(Clone, Copy, PartialEq, Eq, Debug, Hash)] | ||
| pub enum CTy<'tcx> { | ||
| Ty(LTy<'tcx>), | ||
| /// An inference variable. Note that inference variables are scoped to the local function; |
There was a problem hiding this comment.
what is an inference variable?
There was a problem hiding this comment.
is it the state of some variable before its equivalence to a type is determined?
There was a problem hiding this comment.
It's a unification variable as used in type inference.
|
|
||
| #[derive(Clone, Copy, PartialEq, Eq, Debug, Hash)] | ||
| pub enum Constraint<'tcx> { | ||
| /// The set of types for pointer `.0` must contain type `.1`. This is used for "uses" of a |
There was a problem hiding this comment.
what's the notation .N?
There was a problem hiding this comment.
Referring to the anonymous fields of this enum variant, similar to field access in tuples and tuple structs (e.g. let foo = (1, 2); return foo.0;)
| AllTypesCompatible(PointerId), | ||
|
|
||
| /// The set of types for pointer `.0` must be a subset of the set of types for pointer `.1`. | ||
| /// This is used for pointer assignments like `p = q`, among other things. |
There was a problem hiding this comment.
I know it's apparent to those with dataflow familiarity but I think it's worth equating .0 and q and .1 and p in the documentation somehow
There was a problem hiding this comment.
Adjusted comment: 763e88f
|
is this doing equality saturation? it looks very familiar to the approach |
| self.visit_place(pl); | ||
| } | ||
| Rvalue::Aggregate(_, ref ops) => { | ||
| // TODO |
There was a problem hiding this comment.
make TODO more specfic please, i'm not sure what's left to be done
There was a problem hiding this comment.
Made these a little more specific: 5f1a2a1
|
It's a little difficult for me to review this for correctness, especially given there are no tests. How can I be most useful to you here as a reviewer? One of my concerns is that it's all hand-made with no reference to a standard equivalence constraint solving algorithm. We do this in a few places and it seems repetitious and error-prone; please tell me if my concerns are overblown. |
spernsteiner
force-pushed
the
analyze-pointee-type
branch
from
2ab998c to
faeed96
Compare
spernsteiner
changed the base branch from
analyze-pointee-type-base
to
master
This branch adds an analysis that computes a set of possible pointee types for each pointer. It includes only the analysis; the analysis results aren't used to drive any rewriting yet. On
algo_md5, the analysis correctly identifies that the_inputargument toMD5_Updateshould actually point tou8s, that thememsetinli_MD5Transformoperates onu32s, and that thememsetinMD5_Finaloperates on anMD5_CTX.The next step after this will be to use the analysis results in rewriting. We need to rewrite pointer types to use the inferred pointees (such as changing
_input: &c_voidto_input: &[u8]), replacememcpyandmemsetwith safe operations, and (optionally) delete casts that are now no-ops (such asinput = _input as *const c_uchar, onceinputand_inputare both rewritten to&[u8]). This may also require some changes to our currentvoid*cast handling.