tree fb729e6813484499ad983a08ddff844d6b576846
parent 9a2487f94efeb88016a695af823bf26799ef0f06
author buzbee <buzbee@google.com> 1342823807 -0700
committer buzbee <buzbee@google.com> 1343839922 -0700

CFG rework for explicit exception edges

Previously, basic blocks were terminated by any Dalvik opcode
which might throw, and the exception edges were represented
as a list of successor basic blocks.  This resulted in a
SSA renaming bug: any Dalvik register definition caused by
a throwing instruction (such as IGET) would incorrectly be considered
to be visible across the exception edges.  For the Art compiler (and JIT)
this was a benign bug.  But for llvm, it means an invalid CFG.

The other problem this CL is addressing is the llvm bitcode requirement
that all exception edges be explicit.  Because we can't use
the llvm bitcode "invoke" (it doesn't match our exception handling),
all exception edges must be represented as explicit branches in the
bitcode (further contributing to the llvm bitcode bloat).

We split all potentially throwing instructions into two parts: a
check prologue followed by the body.  If there are any catch blocks
associated with the potentially throwing instruction, we make a call
to the intrinisc dex_lang_catch_targets().  Though it should never
expand into actual code, this intrinsic returns a switch key that
feeds into an immediately-following switch statement.  That switch
statement will include edges to all necessary catch blocks, with the
default target referencing the block conaining the "work" portion of
the pair.

Included in this CL are also fixes for .dot file generation
(previously there was an issue with non-unique block names), and an
enhancement to include the block number on Phi incoming arcs.

Also reworked dissasembly to use StringPrintf.

Note: the insertion of new basic blocks following computation of
depth-first-search order badly degrades code layout.  DFS order
computation can be expensive, so I'll be looking for a workaround
in a future CL to avoid a full dfs order regeneration.

With this CL, the device boots, all target tests pass, all methods
are converted to Greenland Bitcode and all well-formed converted methods
pass llvm's function validation pass without error or warning.

We still have some cts failures related to the verifier's
instruction rewriting to THROW_VERIFICATION_ERROR.  In those cases
we can have a malformed graph - but we still must be able to convert
it to legal llvm bitcode.  If executed, it will throw.

We'll detect that situation and bitcast these mismatches away in a
subsequent CL.

Change-Id: I9fa359c912e25ca6a75e2f69d0975126d0687c33