This necessated handling literal versions of the instructions separately
as they had different requirements. The rationale for detecting
unpredictable instructions is because:
a. they are unlikely to be outputted by a well-behaved compiler
b. their behaviour may change between different processors
I would rather unpredictable instructions fail loudly than silently do
approximately the right thing.
The only valid objects to add to the list are those that inherit from
IntrusiveListNode. Therefore anything being added to the list that isn't
inheriting from it will cause compilation to fail.
This generalizes the regular iterator to be compatible with both use
cases. Passing in the list instance directly isn't needed, because the
only way you'd ever get a valid instantiation of an iterator is from a
list instance itself.
GetReturnFromRunCodeAddress is const qualified, so this can accept a const
pointer. This also allows for making the constructor accept a const
pointer as well.
Generalizes MemFnInfo to be compatible with all function types.
Also adds type introspection for arguments, as well as helper templates for the common types supported by all partial specializations.
Considering a HostLocInfo instance houses a std::vector, every time this
function is called can cause a potential heap allocation.
This can be somewhat unnecessary because this function is only used to query
for information we already have.
Considering this is used by several other internal query functions such as
IsRegisterOccupied, IsRegisterAllocated, and IsLastUse, this will result
in better codegen (returning an address is just 3 instructions excluding
the ret instruction for returning, meanwhile heap alloc can be 60+).
This also renames the function to have the same name as its non-const
counterpart, since overloading will just select the correct function
instead of putting that onus on the developer.
