Update dx/tests to 4.3_r2.2
Update dx/junit-tests to 4.3_r2.2
Update dx/etc to 4.3_r2.2
A little instruction format housecleaning and prep work.

Change-Id: Iea9d79d23515090f75cdc32c2123dbfb56e27d3c
Implement the new instruction formats.

I also refactored some of the old code in the process, to minimize
duplication, and I also did a minor cleanup of the format spec.

Change-Id: Ib07ea4ade52aa6ec4fa69000798e0cfb8f10c3a9

Conflicts:
	docs/instruction-formats.html
The failure of dx test 105 wasn't actually spurious. Fixed the code.

In particular, for array load and store instructions, dx was being too
aggressive about letting the contents of the stack override the
implied type expected by the instructions. This led to cases where dx
would emit code instead of reporting an error.

The failure on the array load side of things implied that there also
needed to be a new regression test on the store side, since the
existing array store test didn't catch this. So, I added that too in
this change.

Finally, I took this opportunity to do minor whitespace-type cleanups
in a couple of related files that I opened during the course of the
investigation.

Change-Id: I72c644f66afb1108ae43a129ac81b010d072155a
Added multi-threaded support to processing of class files in dx.

Change-Id: Ideb54c414073a9651b21ce0697e6444fa80f146d
Fix propagation of constants.

In particular, when constructing a rop instruction for a move, if
the source has a known constant value, make the target end up also
having that value.

Change-Id: If172337889134e4a682bb0d8eb4e07ca284ac80e
Up the version number.

Change-Id: Ibf1e0471d1991c0b9ef7df847b427a3aead6fd4d
A bunch of minor cleanups.

I'm reacquainting myself with this code, and figured I might as well
do some of that nit-picky code convention tweakage while I was there.
The only non-whitespace non-comment changes I made were to change the
scope of a couple of methods to be more appropriate.

Change-Id: I550978ed0f5b9ccec938faef7c00d09532832ee4
Always dump blocks in label order.

This removes some cases of spurious test failure. Also did some
minor whitespace and commenting cleanup while I was in the territory.

Change-Id: I6b8f6d0c340625c31bde78394e77abf429367af3

Conflicts:
	dx/tests/091-ssa-const-collector/expected.txt
Line width / spacing tweak.

Change-Id: Idf9c4f56b24e2b150c519f8ed140650183b47a88
More prep work for new opcodes.

The opcode-gen script now expects there to be up to 65536 opcodes, and
it generates opcode chain information. The chaining info isn't used
yet, but eventually it will get hooked into the instruction selection
logic in dx, meaning that dx will no longer have to do relatively
slower opcode searches; the right "next" opcode will have been
staticly generated and compiled in.

I also added a helpful generated comment in RopToDop, which indicates
which opcodes are the ones that *won't* be found by chaining, that is,
which ones are the starts of chains. This is left as a comment and not
code, though, since there are lots of quirks with how these get hooked
up. I hope to make this cleaner at some point, but today's not the day
for it.

Change-Id: I11da833cc57b383733743114c0f3e0e64903982d

Conflicts:
	dx/etc/opcode-gen
	dx/tests/121-sccp/run
Start including the "next opcode" in Dop instances.

Nothing's using it yet, though. Coming soon!

Change-Id: Ide34647fce6ad55fe52c8f6012145b724c134799

Conflicts:
	dx/etc/opcode-gen
	dx/tests/121-sccp/run
Use the static opcode chains in dx.

This removes the need to iterate over all possible opcodes looking for
family/format matches whenever the need arises to rewrite an
instruction with a new opcode. This should speed dx up at least a
little, though I don't know if it will be measurable. It's certainly
cleaner and a bit simpler, though.

Change-Id: I779f19cb1249d30f6886faf76670ae37d5dfc402
Another bit of cleanup.

Making it a little easier to have more than 256 opcodes.

Change-Id: I050050f2b6078407dde4d4f214dec2c1a331000c
Add the new jumbo opcodes to dx...almost.

This change adds the new opcodes while simultaneously preventing
them from actually being emitted, the prevention being controlled
by a new flag in InsnFormat.

Empirically speaking, we already have latent demand for the new
opcodes -- specifically because they allow for wider register
references than their wee companions -- and so we can't actually
enable their generation until the VM is prepared to execute them.

If you're wondering why dx without the new opcodes doesn't crap out on
the register references in question, it's because there's code in dx
which will expand an instruction that has non-fitting register
references into a sequence of two or more instructions, where it
shuffles values into and out of usable registers before and/or after
the instruction. When we turn on the jumbo opcodes, at least some
of these register shuffles will immediately get to go away.

Change-Id: I3f921ab07efa4944d7526fa48534d69f508ac249

Conflicts:
	dx/etc/bytecode.txt
Add const-class/jumbo.

I neglected to include this one in my original list of new opcodes.

Change-Id: Ia59b4b2f21516d851f0398361eb5db1cb413aaab

Conflicts:
	docs/dalvik-bytecode.html
	dx/etc/bytecode.txt
Added info for parallel dx switch "num-threads" to help message.

Change-Id: I7fa31ab7160956c135ab95f8411ad359f616403d
Kill off InsnFormat.nextUp().

This method used to be used during instruction selection, but hasn't
been used since the bytecode.txt file got updated to include format
chains.

Change-Id: Iee827c8b8008a88d56326aecf249299fe92101e1