| commit | 8a012106aade42e0e1f88a6abbfaf798baa991bd | [log] [tgz] |
|---|---|---|
| author | Christoffer Quist Adamsen <christofferqa@google.com> | Wed Jun 27 08:27:43 2018 +0200 |
| committer | Christoffer Quist Adamsen <christofferqa@google.com> | Wed Jun 27 08:27:43 2018 +0200 |
| tree | 59adefc7606b0b1192e3676265f2c9c5b9b31eb3 | |
| parent | 8fab3f59182d503511d7a37167bbab6c17cf74c9 [diff] |
Insert moves for exception after other in-moves This CL addresses an issue in the register allocation involving exception values. PROBLEM: Consider the following IR code. 40: ... 42: v0 <- move-exception 44: ... ... 50: ... v0 ... // 4-bit constrained use of v0 Initially, the liveness interval of v0 is [42; 50[. If the method has overlapping move-exception intervals (and the register allocator needs more than 16 registers), then the intervals of all values defined by a move-exception instruction are split immediately after their definition (commit b6123db40178199abb58d1a01f2d4457d6466b4d). As a result, v0 will now have two liveness intervals: I1=[42; 43[ and I2=[43;50[. When allocating a register for the interval I2, we may need to spill an existing value v1 that is currently active. As a result, we will split the liveness interval of v1 before the start of I2 (i.e., at position 43). The live intervals of v1 after the split therefore becomes J1=[x, y[, J2=[41, 43[, J3=[43, z[. Now, if the registers assigned to J1 and J2 are different, we will create an in-move at position 43 in resolveControlFlow() (not position 41, since the first instruction of the target block is a move-exception instruction). If the the registers assigned to I1 and I2 are also different, then an in-move will also be created at position 43 by the call to addSpillOrRestoreMove() in insertMoves(). If the registers of I2 and J2 are the same (which is a valid assignment), then we will do parallel move scheduling for the following two in-moves: move X, reg(I2) move X, reg(J2) Therefore, there is a risk that we end up with the value that has been spilled instead of the exception object in register X at position 44. FIX: This CL addresses this issue by treating the move "move X, reg(I2)" in the above example as an out-move, such that it will always be inserted after the resolution moves of the current block. Change-Id: Ic36981d85c1b659973526da54b7a1cabec1f58ff
The R8 repo contains two tools:
D8 is a replacement for the DX dexer and R8 is a replacement for the Proguard shrinking and minification tool.
The R8 project uses depot_tools from the chromium project to manage dependencies. Install depot_tools and add it to your path before proceeding.
The R8 project uses Java 8 language features and requires a Java 8 compiler and runtime system.
Typical steps to download and build:
$ git clone https://r8.googlesource.com/r8 $ cd r8 $ tools/gradle.py d8 r8
The tools/gradle.py script will bootstrap using depot_tools to download a version of gradle to use for building on the first run. This will produce two jar files: build/libs/d8.jar and build/libs/r8.jar.
The D8 dexer has a simple command-line interface with only a few options.
The most important option is whether to build in debug or release mode. Debug is the default mode and includes debugging information in the resulting dex files. Debugging information contains information about local variables used when debugging dex code. This information is not useful when shipping final Android apps to users and therefore, final builds should use the --release flag to remove this debugging information to produce smaller dex files.
Typical invocations of D8 to produce dex file(s) in the out directoy:
Debug mode build:
$ java -jar build/libs/d8.jar --output out input.jar
Release mode build:
$ java -jar build/libs/d8.jar --release --output out input.jar
The full set of D8 options can be obtained by running the command line tool with the --help option.
R8 is a Proguard replacement for whole-program optimization, shrinking and minification. R8 uses the Proguard keep rule format for specifying the entry points for an application.
Typical invocations of R8 to produce optimized dex file(s) in the out directory:
$ java -jar build/libs/r8.jar --release --output out --pg-conf proguard.cfg input.jar
The full set of R8 options can be obtained by running the command line tool with the --help option.
Typical steps to run tests:
$ tools/test.py --no_internal
The tools/test.py script will use depot_tools to download a lot of tests and test dependencies on the first run. This includes prebuilt version of the art runtime on which to validate the produced dex code.
In order to contribute to D8/R8 you have to sign the Contributor License Agreement. If your contribution is owned by your employer you need the Corporate Contributor License Agreement.
Once the license agreement is in place, you can upload your patches using ‘git cl’ which is available in depot_tools. Once you have a change that you are happy with you should make sure that it passes all tests and then upload the change to our code review tool using:
$ git cl upload
On your first upload you will be asked to acquire credentials. Follow the instructions given by git cl upload.
On successful uploads a link to the code review is printed in the output of the upload command. In the code review tool you can assign reviewers and mark the change ready for review. At that point the code review tool will send emails to reviewers.
For questions, reach out to us at r8-dev@googlegroups.com.
For D8, find known issues in the D8 issue tracker or file a new D8 bug report.
For R8, find known issues in the R8 issue tracker or file a new R8 bug report.