Restore "CFG rework for explicit exception edges"
Restores, with fix, I9fa359c912e25ca6a75e2f69d0975126d0687c33
Here's the original commit message:
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.
[Update: since this original CL, we've determined that the
THROW_VERIFICATION_ERROR problem is best solved by changes in the
verifier to avoid the problem of malformed code. Structural
verification failures will be treated as hard.]
This reverts commit 937b73eea7a473395f3572e0db1fdc9c6a094db5
Change-Id: I8ba7fe080d8720c14bf74a342403077c150e4a71
9 files changed
