shrink jmp-to-slowpath sequence

_From [derek.br...@gmail.com](https://code.google.com/u/117968039472581148324/) on December 10, 2010 17:58:11_

PR 494769

to shrink the jmp to slowpath sequence:

don't store return pc and derive it from app pc. share single
jmp-to-slowpath for whole bb that stores start pc of fragment, and slowpath
decodes forward until find mov-immed that matches app pc. then return pc
is after the jmp after that mov-immed. but, can't have custom regs holding
app pc since shared jmp-to-slowpath needs to use just one: so don't do this
opt until also have whole-bb stolen reg (which we have now: PR 489221).

try to use jmp-short to shared code: if can't reach then use relay spot, or
duplicated shared code: should save space if > 3 jmp-slowpaths, which
should happen if >128 bytes of code.

additionally: don't store app pc, instead store offs from tag (=> 2-byte
mov_imm). to find tag, either have 1st slowpath entry store full app pc
(== tag) (but then how tell from offs, since off must go to 8-bit
sub-reg?), or have the shared per-bb slowpath entry store it into tls.

alternative: store tag instead of cache start pc, to support traces. then
need to get start pc from tag via DR (have to add API routine: and
disrupt our philosophy of hiding cache).

alternative ideas:
- store pointer to data structure, a la linkstub, instead of both app pc
and return pc. total memory usage goes up but cache footprint goes down.
also, have to delete when fragment deleted: so need hashtable, or embed
data inside fragment: but then cache size up even if executed instrs not.
- jmp to slowpath: don't return to same fragment: instead create a new
fragment. if slowpath rare enough, worth the new fragments and
duplicated tails, since eliminates need for 2nd arg to slowpath.
have to restore eflags in slowpath handler if saved at top of bb.

PR 494769: shrink jmp-to-slowpath sequence, part 1
- Added new type app_loc_t to represent an app pc or an app system call or
for PR 494769 an untranslated app pc
- Bulk of diff is replacing "app_pc pc" and "const char *syscall_aux"
params to various routines with "app_loc_t *loc"
- This is a cleaner way to pass sycalls than the old hack of using
a low pc and passing syscall_aux separately

Server: perforce-panda.eng.vmware.com:1985

PR 494769: shrink jmp-to-slowpath sequence, Part 2
Not yet on by default but just about all there.

Goal is to shrink this:
0x1f845076 c7 c1 b0 f4 a4 00 mov $0x00a4f4b0 -> %ecx
0x1f84507c c7 c2 87 50 84 1f mov $0x1f845087 -> %edx
0x1f845082 e9 72 50 12 00 jmp $0x1f96a0f9

Optimization `#1` (simple):
- use OP_mov_imm to eliminate one byte from each slowpath store
- had to add support for OP_mov_imm for instr operands to core/x86/encode.c

Optimization `#2` (complex):
- eliminate one of the arguments.
decided to go with one of my alternate approach ideas which seemed
simpler and better than the main one: though it still ended up being
complex.

Approach:
- store return pc only
- decode from copy of app instr already present at return point.
walk past spills and restores in between if necessary.
if too much in between (such as adjust-esp instru), or if
DR mangles app instr, use a never-executed clone of app instrs.

List of changes:
- added dr_app_pc_from_cache_pc()
- changed how meta translation is treated when exact non-meta target not
yet hit during translation
- under option -single_arg_slowpath
- using new app_loc_t data structure added in separate commit (Part 1) to
distinguish untranslated pc from system call since there is no clean
sentinel value for both. cache pc is only translated when absolutely
needed, such as to check certain error exceptions, to report an actual
error, or to mark an instr as do-not-share.
- for xl8 sharing, using an additional cache pc entry to increment
the slow path count and avoid xl8 cost on each slowpath.
once over the threshold, xl8 is done to mark the app pc entry
as do-not-share.
- added is_spill_slot_opnd() and improved instr_is_{spill,restore}()

Not enabled by default because of this hole in the implementation: to
handle selfmod and other situations where I can't predict for sure whether
an app instr will remain unmangled I need to add DR support. My plan is to
implement issue #156/PR 306163 and add post-mangling events for both bb and
traces.

_Original issue: http://code.google.com/p/drmemory/issues/detail?id=166_