History log of /dalvik/vm/compiler/codegen/arm/ArmLIR.h
Revision Date Author Comments
ecf8f6ede2c00350a36297dd7427afff9d9cb154 20-Jul-2010 buzbee <buzbee@google.com> JIT: Support for Dalvik volatiles (issue 2781881)

Also, on SMP systems generate memory barriers.

Change-Id: If64f7c98a8de426930b8f36ac77913e53b7b2d7a
fbdcfb9ea9e2a78f295834424c3f24986ea45dac 29-May-2010 Brian Carlstrom <bdc@google.com> Merge remote branch 'goog/dalvik-dev' into dalvik-dev-to-master

Change-Id: I0c0edb3ebf0d5e040d6bbbf60269fab0deb70ef9
b88ec3cbb419b5eac23508dc6b73de2620d7521a 17-May-2010 Ben Cheng <bccheng@android.com> Remove the write permission for the JIT code cache when not needed

To support the feature, redesigned the predicted chaining mechanism so that the
profile count is shared globally in InterpState.

Bug: 2690371
Change-Id: Ifed427e8b1fa4f6c670f19e0761e45e2d4afdbb6
bd0472480c6e876198fe19c4ffa22350c0ce57da 13-May-2010 Bill Buzbee <buzbee@google.com> JIT: Fix for [Issue 2675245] FRF40 monkey crash in jit-cache

The JIT's chaining mechanism suffered from a narrow window that
could result in i-cache inconsistency. One of the forms of chaining
cell consisted of a two 16-bit thumb instruction sequence. If a thread were
interrupted between the execution of those two instructions *and*
another thread picked that moment to convert that cell's
chained/unchained state, then bad things happen.

This CL alters the chain/unchain model somewhat to avoid this case.
Chainable chaining cells grow by 4 bytes each, and instead of rewriting
a 32-bit cell to chain/unchain, we switch between chained and unchained
state by [re]writing the first 16-bits of the cell as either a 16-bit
Thumb unconditional branch (unchained mode) or the first half of a
32-bit Thumb branch. The 2nd 16-bits of the cell will never change once
the cell moves from its inital state - thus avoiding the possibility of it
becoming inconsistent.

This adds a trivial execution penalty on the slow path, but will add
about a kByte of memory usage to a typical process.

Change-Id: Id8b99802e11386cfbab23da6abae10e2d9fc4065
a497359afa1abe4c5780c8799c6fe0edab551c2d 31-Mar-2010 Ben Cheng <bccheng@android.com> Fix a race condition in JIT state refresh under debugging / misc code cleanup.

Bug: 2561283
Change-Id: I9fd94928f3e661de97098808340ea92b28cafa07
1f74863d3e0f19930818398f375ebf1cf2d78969 03-Mar-2010 Bill Buzbee <buzbee@google.com> Jit: Sapphire tuning - mostly scheduling.

Re-enabled load/store motion that had inadvertently been turned off for
non-armv7 targets. Tagged memory references with the kind of memory
they touch (Dalvik frame, literal pool, heap) to enable more aggressive
load hoisting. Eliminated some largely duplicate code in the target
specific files. Reworked temp register allocation code to allocate next
temp round-robin (to improve scheduling opportunities).

Overall, nice gain for Sapphire. Shows 5% to 15% on some benchmarks, and
measurable improvements for Passion.
b4c05977c28c38d2f81b48d0cb15559dc3d05564 25-Feb-2010 Elliott Hughes <enh@google.com> Optimize more easy multiplications by constants.

Rather than make these changes in the libraries (*10 being a common case),
let's do them once and for all in the JIT.

The 2^n-1 case could be better if we generated RSB instructions, but the
current "fake" RSB is still better than a full multiply.

Thumb doesn't support reg/reg/reg/shift instructions, so we can't optimize
the "population count <= 2" cases (such as *10) there.

Tested on sholes, passion, and passion-running-sapphire (and visually
inspected to check we weren't trying to generate Thumb2 instructions there).
Also tested with the self-verifier.
88dc28740f628a8d0d8fe05af0e11443f8793aa1 03-Feb-2010 jeffhao <jeffhao@google.com> Made Self Verification mode's memory interface less intrusive.
9e45c0b968d63ea38353c99252d233879c2efdaf 03-Feb-2010 jeffhao <jeffhao@google.com> Made Self Verification mode's memory interface less intrusive.
c3b92b26df6416d3179e865adccb283ee4170ab1 27-Jan-2010 Ben Cheng <bccheng@android.com> Fix performance issues related to chaining and unchaining.

1) Patching requests for predicted chaining cells (used by virtual/interface
methods) are now batched in a queue and processed when the VM is paused for GC.

2) When the code cache is full the reset operation is also conducted at the
end of GC pauses so this totally eliminates the need for the compiler thread
to issue suspend-all requests. This is a very rare event and when happening it
takes less than 5ms to finish.

3) Change the initial value of the branch in a predicted chaining cell from 0
(ie lsl r0, r0, #0) to 0xe7fe (ie branch to self) so that initializing a
predicted chaining cell doesn't need to suspend all threads. Together with 1)
seeing 20% speedup on some benchmarks.

4) Add TestCompability.c where defining "TEST_VM_IN_ECLAIR := true" in
buildspec.mk will activate dummy symbols needed to run libdvm.so in older
releases.

Bug: 2397689
Bug: 2396513
Bug: 2331313
6999d84e2c55dc4a46a6c311b55bd5811336d9c4 27-Jan-2010 Ben Cheng <bccheng@android.com> Fix performance issues related to chaining and unchaining.

1) Patching requests for predicted chaining cells (used by virtual/interface
methods) are now batched in a queue and processed when the VM is paused for GC.

2) When the code cache is full the reset operation is also conducted at the
end of GC pauses so this totally eliminates the need for the compiler thread
to issue suspend-all requests. This is a very rare event and when happening it
takes less than 5ms to finish.

3) Change the initial value of the branch in a predicted chaining cell from 0
(ie lsl r0, r0, #0) to 0xe7fe (ie branch to self) so that initializing a
predicted chaining cell doesn't need to suspend all threads. Together with 1)
seeing 20% speedup on some benchmarks.

4) Add TestCompability.c where defining "TEST_VM_IN_ECLAIR := true" in
buildspec.mk will activate dummy symbols needed to run libdvm.so in older
releases.

Bug: 2397689
Bug: 2396513
Bug: 2331313
cec26f6ae3347d5ab3d60de02caca2e47151c6b2 16-Jan-2010 Ben Cheng <bccheng@android.com> Fix chaining offset mis-calculation for translations w/ large switch statements.

Bug: 2369821

There are 12 bytes of additional code after the 65th chaining cell. So if a
switch statement with more than that many cases is translated by the JIT, it
will run fine until the next unchaining event, which will patch the wrong code
and lead to all kinds of unexpected crashes.
d0937ef76b41a57d25c084e76aed1bb91c6dfde7 23-Dec-2009 Bill Buzbee <buzbee@google.com> Jit: Update monitor lock/unlock to reflect thinlock changes (I34b20f49)
5d90c20bd7903d7bba966b224e576bf137bf8b4b 23-Nov-2009 Ben Cheng <bccheng@google.com> Restructure the codegen to make architectural depedency explicit.

The original Codegen.c is broken into three components:

- CodegenCommon.c (arch-independend)
- CodegenFactory.c (Thumb1/2 dependent)
- CodegenDriver.c (Dalvik dependent)

For the Thumb/Thumb2 directories, each contain the followin three files:

- Factory.c (low-level routines for instruction selections)
- Gen.c (invoke the ISA-specific instruction selection routines)
- Ralloc.c (arch-dependent register pools)

The FP directory contains FP-specific codegen routines depending on
Thumb/Thumb2/VFP/PortableFP:

- Thumb2VFP.c
- ThumbVFP.c
- ThumbPortableFP.c

Then the hierarchy is formed by stacking these files in the following top-down
order:

1 CodegenCommon.c
2 Thumb[2]/Factory.c
3 CodegenFactory.c
4 Thumb[2]/Gen.c
5 FP stuff
6 Thumb[2]/Ralloc.c
7 CodegenDriver.c
72e93344b4d1ffc71e9c832ec23de0657e5b04a5 13-Nov-2009 Jean-Baptiste Queru <jbq@google.com> eclair snapshot
799cdf9ef24b49a0cac0d22e1f731da01d838b4e 30-Oct-2009 Bill Buzbee <buzbee@google.com> Fixed typo introduced during comment reformatting.
1465db5ee2d3c4c4dcc8e017a294172e858765cb 24-Sep-2009 Bill Buzbee <buzbee@google.com> Major registor allocation rework - stage 1.

Direct usage of registers abstracted out.
Live values tracked locally. Redundant loads and stores suppressed.
Address of registers and register pairs unified w/ single "location" mechanism
Register types inferred using existing dataflow analysis pass.
Interim (i.e. Hack) mechanism for storing register liveness info. Rewrite TBD.
Stubbed-out code for linear scan allocation (for loop and long traces)
Moved optimistic lock check for monitor-enter/exit inline for Thumb2
Minor restructuring, renaming and general cleanup of codegen
Renaming of enums to follow coding convention
Formatting fixes introduced by the enum renaming

Rewrite of RallocUtil.c and addition of linear scan to come in stage 2.
a8e64a7c83ac6fb487a140f77ab8803b46193f45 20-Oct-2009 Ben Cheng <bccheng@google.com> Fix an invoke-interface bug that manifests itself with thread state warnings.

r12 is a scratch register and apparently gcc 4.4 starts to actively use it in
dvmFindInterfaceMethodInCache, the very function that the original live value
is being protected around. This results in useless values setup in the chaining
cell and increases the chances to patch the cell (thus the suspend-all
requests).

Add verbose names for new JIT-related suspend reasons.

With all these changes, the thread state warning will still occur but much less
frequently.

bug 2194174.
d7d426a1d746f70edeaeccf77886f3ad8298e28c 22-Sep-2009 Ben Cheng <bccheng@google.com> Implemented a new scheduler and FP register allocator.

Improved performance by 50% over existing JIT for some FP benchmarks.
dcf3e5d43a1831a166f70cb9e0694cd4b0b356b0 11-Sep-2009 Ben Cheng <bccheng@google.com> Model resource usage for each Thumb/Thumb2 instrution.

This is an mid-point checkin to avoid future merge nightmare for the register
allocator work.
7fb2edd2f69d11435da8dc0f1c251349238863b3 31-Aug-2009 Bill Buzbee <buzbee@google.com> Inline Sqrt bug fix; add support for fp/gen register copies
4238ec2ad1ace5103b2206a483f5f03d2e96c476 25-Aug-2009 Ben Cheng <bccheng@android.com> Implement SSA-based loop optimizations.

For traces of simple natural loops (ie no invokes/side exits) null and range
checks will be hoisted in to entry block.

For acyclic traces SSA representation will be formed but no optimizations are
applied (for now).

SSA representation will be printed with the normal verbose output. For example:

D/dalvikvm( 1248): Dumping LIR insns
D/dalvikvm( 1248): installed code is at 0x428559d4
D/dalvikvm( 1248): total size is 324 bytes
D/dalvikvm( 1248): 0x428559d4 (0000): data 0x012c(300)
D/dalvikvm( 1248): -------- entry offset: 0x002b
D/dalvikvm( 1248): -------- MIR_OP_NULL_N_RANGE_UP_CHECK
D/dalvikvm( 1248): 0x428559d6 (0002): ldr r0, [r5, #36]
D/dalvikvm( 1248): 0x428559d8 (0004): ldr r1, [r5, #12]
D/dalvikvm( 1248): 0x428559da (0006): cbz r0,0x42855a06
D/dalvikvm( 1248): 0x428559dc (0008): ldr r0, [r0, #8]
D/dalvikvm( 1248): 0x428559de (000a): subs r1, #1
D/dalvikvm( 1248): 0x428559e0 (000c): cmp r1, r0
D/dalvikvm( 1248): 0x428559e2 (000e): bge 0x42855a06
D/dalvikvm( 1248): -------- MIR_OP_NULL_N_RANGE_UP_CHECK
D/dalvikvm( 1248): 0x428559e4 (0010): ldr r0, [r5, #40]
D/dalvikvm( 1248): 0x428559e6 (0012): ldr r1, [r5, #12]
D/dalvikvm( 1248): 0x428559e8 (0014): cbz r0,0x42855a06
D/dalvikvm( 1248): 0x428559ea (0016): ldr r0, [r0, #8]
D/dalvikvm( 1248): 0x428559ec (0018): subs r1, #1
D/dalvikvm( 1248): 0x428559ee (001a): cmp r1, r0
D/dalvikvm( 1248): 0x428559f0 (001c): bge 0x42855a06
D/dalvikvm( 1248): -------- MIR_OP_NULL_N_RANGE_UP_CHECK
D/dalvikvm( 1248): 0x428559f2 (001e): ldr r0, [r5, #32]
D/dalvikvm( 1248): 0x428559f4 (0020): ldr r1, [r5, #12]
D/dalvikvm( 1248): 0x428559f6 (0022): cbz r0,0x42855a06
D/dalvikvm( 1248): 0x428559f8 (0024): ldr r0, [r0, #8]
D/dalvikvm( 1248): 0x428559fa (0026): cmp r1, r0
D/dalvikvm( 1248): 0x428559fc (0028): bge 0x42855a06
D/dalvikvm( 1248): -------- MIR_OP_LOWER_BOUND_CHECK
D/dalvikvm( 1248): 0x428559fe (002a): ldr r0, [r5, #44]
D/dalvikvm( 1248): 0x42855a00 (002c): cmp r0, #1
D/dalvikvm( 1248): 0x42855a02 (002e): blt 0x42855a06
D/dalvikvm( 1248): 0x42855a04 (0030): b 0x42855a08
D/dalvikvm( 1248): 0x42855a06 (0032): b 0x42855af0
D/dalvikvm( 1248): L0x002b:
D/dalvikvm( 1248): -------- MIR_OP_PHI
D/dalvikvm( 1248): -------- s20(v11_1) <- s11(v11_0) s46(v11_2)
D/dalvikvm( 1248): -------- dalvik offset: 0x002b @ aget-wide
D/dalvikvm( 1248): -------- s21(v12_1) s22(v13_1) <- s9(v9_0) s20(v11_1)
D/dalvikvm( 1248): 0x42855a08 (0034): ldr r2, [r5, #36]
D/dalvikvm( 1248): 0x42855a0a (0036): ldr r3, [r5, #44]
D/dalvikvm( 1248): 0x42855a0c (0038): adds r2, r2, #16
D/dalvikvm( 1248): 0x42855a0e (003a): lsls r3, r3, #3
D/dalvikvm( 1248): 0x42855a10 (003c): ldr r0, [r2, r3]
D/dalvikvm( 1248): 0x42855a12 (003e): adds r2, r2, #4
D/dalvikvm( 1248): 0x42855a14 (0040): ldr r1, [r2, r3]
D/dalvikvm( 1248): -------- dalvik offset: 0x002d @ aget-wide
D/dalvikvm( 1248): -------- s23(v14_1) s24(v15_1) <- s10(v10_0) s20(v11_1)
D/dalvikvm( 1248): 0x42855a16 (0042): ldr r3, [r5, #40]
D/dalvikvm( 1248): 0x42855a18 (0044): str r0, [r5, #48]
D/dalvikvm( 1248): 0x42855a1a (0046): ldr r0, [r5, #44]
D/dalvikvm( 1248): 0x42855a1c (0048): adds r3, r3, #16
D/dalvikvm( 1248): 0x42855a1e (004a): lsls r0, r0, #3
D/dalvikvm( 1248): 0x42855a20 (004c): str r1, [r5, #52]
D/dalvikvm( 1248): 0x42855a22 (004e): ldr r1, [r3, r0]
D/dalvikvm( 1248): 0x42855a24 (0050): adds r3, r3, #4
D/dalvikvm( 1248): 0x42855a26 (0052): ldr r2, [r3, r0]
D/dalvikvm( 1248): -------- dalvik offset: 0x002f @ add-double/2addr
D/dalvikvm( 1248): -------- s25(v12_2) s26(v13_2) <- s21(v12_1) s22(v13_1) s23(v14_1) s24(v15_1)
D/dalvikvm( 1248): 0x42855a28 (0054): str r1, [r5, #56]
D/dalvikvm( 1248): 0x42855a2a (0056): str r2, [r5, #60]
D/dalvikvm( 1248): 0x42855a2c (0058): vldr d1, [r5, #48]
D/dalvikvm( 1248): 0x42855a30 (005c): vldr d2, [r5, #56]
D/dalvikvm( 1248): 0x42855a34 (0060): vadd d0, d1, d2
D/dalvikvm( 1248): -------- dalvik offset: 0x0030 @ const/4
D/dalvikvm( 1248): -------- s27(v14_2) <-
D/dalvikvm( 1248): 0x42855a38 (0064): movs r2, #1
D/dalvikvm( 1248): -------- dalvik offset: 0x0031 @ sub-int
D/dalvikvm( 1248): -------- s28(v14_3) <- s20(v11_1) s27(v14_2)
D/dalvikvm( 1248): 0x42855a3a (0066): ldr r3, [r5, #44]
D/dalvikvm( 1248): 0x42855a3c (0068): subs r0, r3, r2
D/dalvikvm( 1248): -------- dalvik offset: 0x0033 @ aget-wide
D/dalvikvm( 1248): -------- s29(v14_4) s30(v15_2) <- s8(v8_0) s28(v14_3)
D/dalvikvm( 1248): 0x42855a3e (006a): ldr r3, [r5, #32]
D/dalvikvm( 1248): 0x42855a40 (006c): adds r3, r3, #16
D/dalvikvm( 1248): 0x42855a42 (006e): str r0, [r5, #56]
D/dalvikvm( 1248): 0x42855a44 (0070): lsls r0, r0, #3
D/dalvikvm( 1248): 0x42855a46 (0072): vstr d0, [r5, #48]
D/dalvikvm( 1248): 0x42855a4a (0076): ldr r1, [r3, r0]
D/dalvikvm( 1248): 0x42855a4c (0078): adds r3, r3, #4
D/dalvikvm( 1248): 0x42855a4e (007a): ldr r2, [r3, r0]
D/dalvikvm( 1248): -------- dalvik offset: 0x0035 @ add-double/2addr
D/dalvikvm( 1248): -------- s31(v12_3) s32(v13_3) <- s25(v12_2) s26(v13_2) s29(v14_4) s30(v15_2)
D/dalvikvm( 1248): 0x42855a50 (007c): str r1, [r5, #56]
D/dalvikvm( 1248): 0x42855a52 (007e): str r2, [r5, #60]
D/dalvikvm( 1248): 0x42855a54 (0080): vldr d1, [r5, #48]
D/dalvikvm( 1248): 0x42855a58 (0084): vldr d2, [r5, #56]
D/dalvikvm( 1248): 0x42855a5c (0088): vadd d0, d1, d2
D/dalvikvm( 1248): -------- dalvik offset: 0x0036 @ add-int/lit8
D/dalvikvm( 1248): -------- s33(v14_5) <- s20(v11_1)
D/dalvikvm( 1248): 0x42855a60 (008c): ldr r2, [r5, #44]
D/dalvikvm( 1248): 0x42855a62 (008e): adds r2, r2, #1
D/dalvikvm( 1248): -------- dalvik offset: 0x0038 @ aget-wide
D/dalvikvm( 1248): -------- s34(v14_6) s35(v15_3) <- s8(v8_0) s33(v14_5)
D/dalvikvm( 1248): 0x42855a64 (0090): ldr r1, [r5, #32]
D/dalvikvm( 1248): 0x42855a66 (0092): adds r1, r1, #16
D/dalvikvm( 1248): 0x42855a68 (0094): str r2, [r5, #56]
D/dalvikvm( 1248): 0x42855a6a (0096): lsls r2, r2, #3
D/dalvikvm( 1248): 0x42855a6c (0098): vstr d0, [r5, #48]
D/dalvikvm( 1248): 0x42855a70 (009c): ldr r3, [r1, r2]
D/dalvikvm( 1248): 0x42855a72 (009e): adds r1, r1, #4
D/dalvikvm( 1248): 0x42855a74 (00a0): ldr r0, [r1, r2]
D/dalvikvm( 1248): -------- dalvik offset: 0x003a @ add-double/2addr
D/dalvikvm( 1248): -------- s36(v12_4) s37(v13_4) <- s31(v12_3) s32(v13_3) s34(v14_6) s35(v15_3)
D/dalvikvm( 1248): 0x42855a76 (00a2): str r3, [r5, #56]
D/dalvikvm( 1248): 0x42855a78 (00a4): str r0, [r5, #60]
D/dalvikvm( 1248): 0x42855a7a (00a6): vldr d1, [r5, #48]
D/dalvikvm( 1248): 0x42855a7e (00aa): vldr d2, [r5, #56]
D/dalvikvm( 1248): 0x42855a82 (00ae): vadd d0, d1, d2
D/dalvikvm( 1248): 0x42855a86 (00b2): vstr d0, [r5, #48]
D/dalvikvm( 1248): -------- dalvik offset: 0x003b @ mul-double/2addr
D/dalvikvm( 1248): -------- s38(v12_5) s39(v13_5) <- s36(v12_4) s37(v13_4) s4(v4_0) s5(v5_0)
D/dalvikvm( 1248): 0x42855a8a (00b6): vmov.f64 s2, s0
D/dalvikvm( 1248): 0x42855a8e (00ba): vldr d2, [r5, #16]
D/dalvikvm( 1248): 0x42855a92 (00be): vmuld d0, d1, d2
D/dalvikvm( 1248): -------- dalvik offset: 0x003c @ aget-wide
D/dalvikvm( 1248): -------- s40(v14_7) s41(v15_4) <- s8(v8_0) s20(v11_1)
D/dalvikvm( 1248): 0x42855a96 (00c2): ldr r2, [r5, #32]
D/dalvikvm( 1248): 0x42855a98 (00c4): ldr r3, [r5, #44]
D/dalvikvm( 1248): 0x42855a9a (00c6): adds r2, r2, #16
D/dalvikvm( 1248): 0x42855a9c (00c8): lsls r3, r3, #3
D/dalvikvm( 1248): 0x42855a9e (00ca): vstr d0, [r5, #48]
D/dalvikvm( 1248): 0x42855aa2 (00ce): ldr r0, [r2, r3]
D/dalvikvm( 1248): 0x42855aa4 (00d0): adds r2, r2, #4
D/dalvikvm( 1248): 0x42855aa6 (00d2): ldr r1, [r2, r3]
D/dalvikvm( 1248): 0x42855aa8 (00d4): str r0, [r5, #56]
D/dalvikvm( 1248): 0x42855aaa (00d6): str r1, [r5, #60]
D/dalvikvm( 1248): -------- dalvik offset: 0x003e @ mul-double
D/dalvikvm( 1248): -------- s42(v14_8) s43(v15_5) <- s40(v14_7) s41(v15_4) s16(v16_0) s17(v17_0)
D/dalvikvm( 1248): 0x42855aac (00d8): vldr d1, [r5, #56]
D/dalvikvm( 1248): 0x42855ab0 (00dc): vldr d2, [r5, #64]
D/dalvikvm( 1248): 0x42855ab4 (00e0): vmuld d0, d1, d2
D/dalvikvm( 1248): 0x42855ab8 (00e4): vstr d0, [r5, #56]
D/dalvikvm( 1248): -------- dalvik offset: 0x0040 @ add-double/2addr
D/dalvikvm( 1248): -------- s44(v12_6) s45(v13_6) <- s38(v12_5) s39(v13_5) s42(v14_8) s43(v15_5)
D/dalvikvm( 1248): 0x42855abc (00e8): vldr d1, [r5, #48]
D/dalvikvm( 1248): 0x42855ac0 (00ec): vldr d2, [r5, #56]
D/dalvikvm( 1248): 0x42855ac4 (00f0): vadd d0, d1, d2
D/dalvikvm( 1248): 0x42855ac8 (00f4): vstr d0, [r5, #48]
D/dalvikvm( 1248): -------- dalvik offset: 0x0041 @ aput-wide
D/dalvikvm( 1248): -------- s44(v12_6) s45(v13_6) s8(v8_0) s20(v11_1)
D/dalvikvm( 1248): 0x42855acc (00f8): ldr r3, [r5, #32]
D/dalvikvm( 1248): 0x42855ace (00fa): ldr r0, [r5, #44]
D/dalvikvm( 1248): 0x42855ad0 (00fc): adds r3, r3, #16
D/dalvikvm( 1248): 0x42855ad2 (00fe): ldr r1, [r5, #48]
D/dalvikvm( 1248): 0x42855ad4 (0100): ldr r2, [r5, #52]
D/dalvikvm( 1248): 0x42855ad6 (0102): lsls r0, r0, #3
D/dalvikvm( 1248): 0x42855ad8 (0104): str r1, [r3, r0]
D/dalvikvm( 1248): 0x42855ada (0106): adds r3, r3, #4
D/dalvikvm( 1248): 0x42855adc (0108): str r2, [r3, r0]
D/dalvikvm( 1248): -------- dalvik offset: 0x0043 @ add-int/lit8
D/dalvikvm( 1248): -------- s46(v11_2) <- s20(v11_1)
D/dalvikvm( 1248): 0x42855ade (010a): ldr r2, [r5, #44]
D/dalvikvm( 1248): 0x42855ae0 (010c): adds r2, r2, #1
D/dalvikvm( 1248): 0x42855ae2 (010e): str r2, [r5, #44]
D/dalvikvm( 1248): -------- dalvik offset: 0x0045 @ goto
D/dalvikvm( 1248): --------
D/dalvikvm( 1248): L0x0029:
D/dalvikvm( 1248): -------- dalvik offset: 0x0029 @ if-ge
D/dalvikvm( 1248): -------- s46(v11_2) s3(v3_0)
D/dalvikvm( 1248): 0x42855ae4 (0110): ldr r0, [r5, #44]
D/dalvikvm( 1248): 0x42855ae6 (0112): ldr r1, [r5, #12]
D/dalvikvm( 1248): 0x42855ae8 (0114): cmp r0, r1
D/dalvikvm( 1248): 0x42855aea (0116): bge 0x42855aee
D/dalvikvm( 1248): 0x42855aec (0118): b 0x42855a08
D/dalvikvm( 1248): -------- exit offset: 0x0046
D/dalvikvm( 1248): 0x42855aee (011a): b 0x42855af8
D/dalvikvm( 1248): -------- reconstruct dalvik PC : 0x42a644d6 @ +0x002b
D/dalvikvm( 1248): 0x42855af0 (011c): ldr r0, [pc, #32]
D/dalvikvm( 1248): Exception_Handling:
D/dalvikvm( 1248): 0x42855af2 (011e): ldr r1, [r6, #84]
D/dalvikvm( 1248): 0x42855af4 (0120): blx r1
D/dalvikvm( 1248): 0x42855af6 (0122): .align4
D/dalvikvm( 1248): -------- chaining cell (normal): 0x0046
D/dalvikvm( 1248): 0x42855af8 (0124): ldr r0, [r6, #76]
D/dalvikvm( 1248): 0x42855afa (0126): blx r0
D/dalvikvm( 1248): 0x42855afc (0128): data 0x450c(17676)
D/dalvikvm( 1248): 0x42855afe (012a): data 0x42a6(17062)
D/dalvikvm( 1248): 0x42855b14 (0140): .word (0x42a644d6)
D/dalvikvm( 1248): End Ljnt/scimark2/SOR;execute, 18 Dalvik instructions
a4a7f0708e75eefae8cf9fff3f9e15699f7881be 27-Aug-2009 Bill Buzbee <buzbee@google.com> Improved codegen for inline, continuing codegen restructuring

Added support for Thumb2 IT. Moved compare-long and floating point
comparisons inline. Temporarily disabled use of Thumb2 CBZ & CBNZ
because they were causing too many out-of-range assembly restarts.
Bug fix for LIR3 assert.
270c1d64a192341be842f46734054c692bac061e 14-Aug-2009 Bill Buzbee <buzbee@google.com> Thumb/Thumb2 instruction selection rework.

Change-id: I7428278f07f49e675d0271c58b3cbf1f6a4e9da1
97319a8a234e9fe1cf90ca39aa6eca37d729afd5 13-Aug-2009 Jeff Hao <jeffhao@google.com> New changes to enable self verification mode.
7ea0f64d067cd8a2213c2c04a3291335c34d9602 11-Aug-2009 Bill Buzbee <buzbee@google.com> Continuing evolution of Thumb2 support.
Bug fix for local optimization
Enable partial floating point store sinking (with significant perf gain!)
9727c3de12ab9daed0d92f6da2f5c0b0169e698d 01-Aug-2009 Bill Buzbee <buzbee@google.com> Fixed 2 floating point bugs; improved debug output; armv7-a thumb2 inline sqrt
9bc3df373ae6f4f7e6e97d554884d4e0dbad5494 30-Jul-2009 Bill Buzbee <buzbee@google.com> Stage 3 of Thumb2 support. armv7-a now generates vfp code inline.
89efc3d632adfa076bd622369b1ad8e4b49cf20e 28-Jul-2009 Bill Buzbee <buzbee@google.com> Stage 2 of structural changes for support of THUMB2. No logic changes.