Fix (most?) DefLabel issues with pdce-inlining

Fix (most?) DefLabel issues with pdce-inlining

Summary:
The pdce-inlining frame optimization pass didn't tolerate
DefLabels of frames very well. The optimize phase is relatively easy
to deal with. We just decline to optimize any FramePtrs defined by a
DefLabel or used by a DefLabel (the later was already true). The
analysis phase is trickier, however (mainly to avoid asserting on
broken invariants). To deal with this, instead of keeping a single
"current FP", we instead keep a set of "current FPs". In most cases,
the set will only consider a single FP. However if the current FP is
defined by a DefLabel, and we encounter an InlineReturn or
InlineSuspend, we do not know which FP is active (because it could be
either input to the DefLabel). Instead, we mark both as "current". In
addition, whenever we need to perform an operation using these frame
pointers, we "resolve" them. This means walking upward and seeing how
they're defined. If they're defined by a DefFP or DefInlineFP, then
they're resolved to themselves. Otherwise, we recursively walk through
the DefLabel and do the same for its operands. Thus resolving a single
FP might result in a set. This ensures that we treat the DefLabels as
transparent. To avoid lots of redundant look back, the resolutions are
cached.

Also fix a bug in normal DCE where we also weren't dealing with
DefLabels properly.

Reviewed By: jano

Differential Revision: D16216150

fbshipit-source-id: c1c3b448bfac3b7149ac536f65dab7a81a4683e4