Introduce a Mem component in jit::Type
commitfd7c6329a0dc0e87e2bc6eaa621bab2af5b9f15e
authorBrett Simmers <bsimmers@fb.com>
Sat, 7 Jul 2018 23:30:27 +0000 (7 16:30 -0700)
committerHhvm Bot <hhvm-bot@users.noreply.github.com>
Sat, 7 Jul 2018 23:43:58 +0000 (7 16:43 -0700)
tree08a87350fb2bd12f53c5f63bbfd23485d7054eef
parenta4a1122697fdc7b2710b26f86d0affc2e2ca6213
Introduce a Mem component in jit::Type

Summary:
This new Type component encodes information about memory addresses (as
opposed to Ptr, which describes the pointee of the memory address). It will be
used for tv_val<> values in the jit. Note that we have Mem::Lval but not
Mem::Rval. There are a few reasons for this:
- The distinction between tv_lval/tv_rval in C++ is entirely for
  const-correctness; their bit representations are exactly the same.
- We don't distinguish between const TypedValue* and TypedValue* in the jit;
  there's just TPtrToFoo.
- I'm not convinced that tv_rval even needs to exist long-term. With the
  exception of the few uses of tv_rval::as_lval(), all uses of tv_rval could
  instead pass around a TypedValue. Especially in a potential future world
  where tv_val<> is a pair of pointers, it would be better to pass around a
  TypedValue when possible rather than a tv_rval.

For all hhir-related purposes exception codegen, both TPtrToFoo and TLvalToFoo
represent a pointer to a TypedValue. TMemToFoo represents this shared concept
between the two, and is used to find pointers in places like
memory-effects. However, the two types will eventually have different
representations, so we can never have concrete values that are TMemToFoo; they
must always be TPtrToFoo or TMemToFoo.

Reviewed By: paulbiss

Differential Revision: D4862901

fbshipit-source-id: 58e798a61778d8670e6db30a9c34621849c301f9
hphp/runtime/test/type.cpp
hphp/runtime/vm/jit/check.cpp
hphp/runtime/vm/jit/ssa-tmp.cpp
hphp/runtime/vm/jit/type-inl.h
hphp/runtime/vm/jit/type.cpp
hphp/runtime/vm/jit/type.h