summaryrefslogtreecommitdiffstats
path: root/dx/tests
Commit message (Collapse)AuthorAgeFilesLines
* Fixes unnecessary multi-merge steps.Esteban de la Canal2015-10-133-22/+35
| | | | | | | | Changes merging from quadratic in the number of classes to linear. This has a tremendous speed up while merging many dexes at the same time. A sample test (iosched app) with 29 dexes goes from 6 seconds to 1. Change-Id: Iff02a0dc44d098b0878e88d18f5f4083804a6495
* am 7b153a1d: Merge "Fix potential dex index overflow in dx" into lmp-mr1-devBenoit Lamarche2015-04-081-0/+1
|\ | | | | | | | | * commit '7b153a1d75a3f51d38e5742df142f58a82f14fe3': Fix potential dex index overflow in dx
| * Fix potential dex index overflow in dxPeter Jensen2015-04-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Revert change to dex rotation algorithm made as part of commit: 845d9d0eed0f6556e11ee7f7204fda9c8dd41154 Bug: https://code.google.com/p/android/issues/detail?id=161887 Signed-off-by: Peter Jensen <jensenp@google.com> (cherry picked from commit d024c06726c7e119ee76395611aa7cfe3b0a8b7e) Change-Id: Iede742620854cef3542bf98b77e66aa8a305195e
* | resolved conflicts for merge of 6be6ed44 to lmp-mr1-dev-plus-aospBenoit Lamarche2015-04-081-1/+0
|\| | | | | | | Change-Id: Id603b84943b1cb244b69272b4c8607a520c517b2
| * Support --num-threads with --multi-dex (take 2)Peter Jensen2015-04-0711-1/+258
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With fix for regression introduced in original commit. The current dx implementation supports options --multi-dex, for applications not fitting within the dex format limitations; and --num-threads=N, triggers concurrent processing of multiple input files. However, the implementation has the following limitations: The --num-threads option is disabled when used together with --multi-dex. The --num-threads option implements concurrency at the level of classpath entries, and does nothing when the classes to be translated are specified with a single classpath element (e.g. single jar output from Proguard). The existing --num-threads implementation may produce indeterministic output. The heuristic used by the --multi-dex option to determine when to rotate the dex output file is overly conservative. The primary objective of this change is: Concurrent translation of classes, independently of input specification format. Support --num-threads=N in both mono- and multi-dex mode. Deterministic class output order. Near optimal use of dex file format capacity. This is accomplished by reorganizing the dx workflow in a pipeline of concurrent phases. read-class | parse-class | translate-class | add-to-dex | convert-dex-to-byte[]; output-dex-files-or-jar To manage dex file rotation (i.e. --multi-dex support), the parse-class and add-to-dex phases are synchronized to prevent forwarding classes to the translate-class phase if it could potentially result in breaking the dex format limitations. The heuristic currently used to estimate the number of indices needed for a class is improved, to minimize the amount of serialization imposed by this feedback mechanism, and to improve the use of dex file capacity. The translate-class and convert-dex-to-byte[] phases are further parallelized with configurable (--num-threads=N option) thread pools. This allow translating classes concurrently, while also performing output conversion in parallel. Separate collector threads are used to collect results from the thread pools in deterministic order. Testing was performed on an Ubuntu system, with 6 cores and 12 hardware threads. The taskset command was used to experimentally establish that running with more than 8 hardware threads does not provide any additional benefit. Experiments shows that the argument to --num-threads should not exceed the lesser of the number of available hardware threads, and 5. Setting it to a higher value results in no additional benefit. The gain is generally larger for larger applications, and not significant for small applications with less than a few thousands classes. Experiments with generated classes shows that for large applications gains as high as 50% may be possible. For an existing real-life application with more than 11k classes, and requiring 2 dex files, a speed-up of 37% was achieved (--num-threads=5, 8 hardware threads, 4g Java heap). A speedup of 31% was observed for another application with ~7 classes. For small applications, use of --num-threads=N>1 doesn’t provide significant benefit. Running with --num-threads=1, the modified dx is slightly faster, but no significant gain is observed unless the application requires multiple dex files. The one case where a significant regression may be observed is when using --num-threads=N>1, with a single hardware thread. This is an inappropriate configuration, even with the current implementation. However, because of the limitations of the current implementation, such configurations may exist. For instance, a configuration using both --multi-dex and --num-threads=5 will currently generate a warning about using the two options together. With the new implementation, the options can legitimately be used together, and could result in an ~20% regression running on a single hardware thread. Note: the current dx implementation, without --num-threads option, is already approximately 50% slower with 1 hardware thread, compared to running with 2 or more. With 2 hardware threads the implementations are practically at par (a little better, or a little worse, depending on the application). Testing: Tested with 6 existing applications ranging in size from 1K - 12K classes. Updated and tested with relevant existing unit tests (one test changed to account for better dex rotation heuristic). Added unit test to test deterministic output. Added unit performance test. By default run script merely validates that --multi-dex and --num-threads can be used together (fast). However, the test is configurable to perform performance test, over sets of generated classes. Signed-off-by: Peter Jensen <jensenp@google.com> (cherry picked from commit 845d9d0eed0f6556e11ee7f7204fda9c8dd41154) (cherry picked from commit dd140a22d90495045024334a91770acaad8e065e) Change-Id: I33a8ea0451efc0af7eb1d72e80cb926d6583d569
| * Renumber dx test multidex-option-overflow to 128.Yohann Roussel2014-07-233-0/+0
| | | | | | | | | | | | | | | | Because there were 2 tests 123. (cherry picked from commit d3fb68891cffc4e43cff49d46e30d511dc6f1315) Change-Id: Ic6df7590ab32893a40e42ea145d04c64cc265308
| * am a0433557: am 8b68699e: Merge "Remove dx/tests/120-disable-extend-ops"Narayan Kamath2014-03-124-118/+0
| |\ | | | | | | | | | | | | * commit 'a0433557ef5d7ffc75fca4d3f583540c8f75e70e': Remove dx/tests/120-disable-extend-ops
| * \ am 3014c365: am dc003e0f: Merge "Transform incorrect invokevirtual ops to ↵Narayan Kamath2014-03-115-0/+62
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | invokedirect." * commit '3014c36515e2eae4a53dd697c82ffb5333d95292': Transform incorrect invokevirtual ops to invokedirect.
| * \ \ Merge "Add DexMerge stress test"Benoit Lamarche2013-12-044-0/+63
| |\ \ \
| | * | | Add DexMerge stress testBenoit Lamarche2013-12-034-0/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also add use of DexIndexOverflowException Change-Id: Ibe721d026ec7a4a26280701f45369f3d271130ce
| * | | | Add tests about dx multidex options.Yohann Roussel2013-12-0219-0/+308
| |/ / / | | | | | | | | | | | | Change-Id: Ib41d9970976fd8e96b4b2c2d900b123d13965082
* | | | Fix potential dex index overflow in dxPeter Jensen2015-03-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert change to dex rotation algorithm made as part of commit: 845d9d0eed0f6556e11ee7f7204fda9c8dd41154 Bug: https://code.google.com/p/android/issues/detail?id=161887 Change-Id: I255aa52b74c921a78e77671ae6187157fef011e1 Signed-off-by: Peter Jensen <jensenp@google.com>
* | | | Support --num-threads with --multi-dex (take 2)Peter Jensen2015-02-0911-1/+258
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With fix for regression introduced in original commit. The current dx implementation supports options --multi-dex, for applications not fitting within the dex format limitations; and --num-threads=N, triggers concurrent processing of multiple input files. However, the implementation has the following limitations: The --num-threads option is disabled when used together with --multi-dex. The --num-threads option implements concurrency at the level of classpath entries, and does nothing when the classes to be translated are specified with a single classpath element (e.g. single jar output from Proguard). The existing --num-threads implementation may produce indeterministic output. The heuristic used by the --multi-dex option to determine when to rotate the dex output file is overly conservative. The primary objective of this change is: Concurrent translation of classes, independently of input specification format. Support --num-threads=N in both mono- and multi-dex mode. Deterministic class output order. Near optimal use of dex file format capacity. This is accomplished by reorganizing the dx workflow in a pipeline of concurrent phases. read-class | parse-class | translate-class | add-to-dex | convert-dex-to-byte[]; output-dex-files-or-jar To manage dex file rotation (i.e. --multi-dex support), the parse-class and add-to-dex phases are synchronized to prevent forwarding classes to the translate-class phase if it could potentially result in breaking the dex format limitations. The heuristic currently used to estimate the number of indices needed for a class is improved, to minimize the amount of serialization imposed by this feedback mechanism, and to improve the use of dex file capacity. The translate-class and convert-dex-to-byte[] phases are further parallelized with configurable (--num-threads=N option) thread pools. This allow translating classes concurrently, while also performing output conversion in parallel. Separate collector threads are used to collect results from the thread pools in deterministic order. Testing was performed on an Ubuntu system, with 6 cores and 12 hardware threads. The taskset command was used to experimentally establish that running with more than 8 hardware threads does not provide any additional benefit. Experiments shows that the argument to --num-threads should not exceed the lesser of the number of available hardware threads, and 5. Setting it to a higher value results in no additional benefit. The gain is generally larger for larger applications, and not significant for small applications with less than a few thousands classes. Experiments with generated classes shows that for large applications gains as high as 50% may be possible. For an existing real-life application with more than 11k classes, and requiring 2 dex files, a speed-up of 37% was achieved (--num-threads=5, 8 hardware threads, 4g Java heap). A speedup of 31% was observed for another application with ~7 classes. For small applications, use of --num-threads=N>1 doesn’t provide significant benefit. Running with --num-threads=1, the modified dx is slightly faster, but no significant gain is observed unless the application requires multiple dex files. The one case where a significant regression may be observed is when using --num-threads=N>1, with a single hardware thread. This is an inappropriate configuration, even with the current implementation. However, because of the limitations of the current implementation, such configurations may exist. For instance, a configuration using both --multi-dex and --num-threads=5 will currently generate a warning about using the two options together. With the new implementation, the options can legitimately be used together, and could result in an ~20% regression running on a single hardware thread. Note: the current dx implementation, without --num-threads option, is already approximately 50% slower with 1 hardware thread, compared to running with 2 or more. With 2 hardware threads the implementations are practically at par (a little better, or a little worse, depending on the application). Testing: Tested with 6 existing applications ranging in size from 1K - 12K classes. Updated and tested with relevant existing unit tests (one test changed to account for better dex rotation heuristic). Added unit test to test deterministic output. Added unit performance test. By default run script merely validates that --multi-dex and --num-threads can be used together (fast). However, the test is configurable to perform performance test, over sets of generated classes. Signed-off-by: Peter Jensen <jensenp@google.com> (cherry picked from commit 845d9d0eed0f6556e11ee7f7204fda9c8dd41154) Change-Id: I721effa31c3b1a8b427d3a18ec554a19c5e9765b
* | | | Revert "Support --num-threads with --multi-dex"Benoit Lamarche2015-02-0911-258/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 845d9d0eed0f6556e11ee7f7204fda9c8dd41154. Bug: 19313927 Change-Id: Ia6582a3914cc33762aef74da1f5a6a153c8c0ab2
* | | | Support --num-threads with --multi-dexPeter Jensen2014-12-2211-1/+258
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current dx implementation supports options --multi-dex, for applications not fitting within the dex format limitations; and --num-threads=N, triggers concurrent processing of multiple input files. However, the implementation has the following limitations: The --num-threads option is disabled when used together with --multi-dex. The --num-threads option implements concurrency at the level of classpath entries, and does nothing when the classes to be translated are specified with a single classpath element (e.g. single jar output from Proguard). The existing --num-threads implementation may produce indeterministic output. The heuristic used by the --multi-dex option to determine when to rotate the dex output file is overly conservative. The primary objective of this change is: Concurrent translation of classes, independently of input specification format. Support --num-threads=N in both mono- and multi-dex mode. Deterministic class output order. Near optimal use of dex file format capacity. This is accomplished by reorganizing the dx workflow in a pipeline of concurrent phases. read-class | parse-class | translate-class | add-to-dex | convert-dex-to-byte[]; output-dex-files-or-jar To manage dex file rotation (i.e. --multi-dex support), the parse-class and add-to-dex phases are synchronized to prevent forwarding classes to the translate-class phase if it could potentially result in breaking the dex format limitations. The heuristic currently used to estimate the number of indices needed for a class is improved, to minimize the amount of serialization imposed by this feedback mechanism, and to improve the use of dex file capacity. The translate-class and convert-dex-to-byte[] phases are further parallelized with configurable (--num-threads=N option) thread pools. This allow translating classes concurrently, while also performing output conversion in parallel. Separate collector threads are used to collect results from the thread pools in deterministic order. Testing was performed on an Ubuntu system, with 6 cores and 12 hardware threads. The taskset command was used to experimentally establish that running with more than 8 hardware threads does not provide any additional benefit. Experiments shows that the argument to --num-threads should not exceed the lesser of the number of available hardware threads, and 5. Setting it to a higher value results in no additional benefit. The gain is generally larger for larger applications, and not significant for small applications with less than a few thousands classes. Experiments with generated classes shows that for large applications gains as high as 50% may be possible. For an existing real-life application with more than 11k classes, and requiring 2 dex files, a speed-up of 37% was achieved (--num-threads=5, 8 hardware threads, 4g Java heap). A speedup of 31% was observed for another application with ~7 classes. For small applications, use of --num-threads=N>1 doesn’t provide significant benefit. Running with --num-threads=1, the modified dx is slightly faster, but no significant gain is observed unless the application requires multiple dex files. The one case where a significant regression may be observed is when using --num-threads=N>1, with a single hardware thread. This is an inappropriate configuration, even with the current implementation. However, because of the limitations of the current implementation, such configurations may exist. For instance, a configuration using both --multi-dex and --num-threads=5 will currently generate a warning about using the two options together. With the new implementation, the options can legitimately be used together, and could result in an ~20% regression running on a single hardware thread. Note: the current dx implementation, without --num-threads option, is already approximately 50% slower with 1 hardware thread, compared to running with 2 or more. With 2 hardware threads the implementations are practically at par (a little better, or a little worse, depending on the application). Testing: Tested with 6 existing applications ranging in size from 1K - 12K classes. Updated and tested with relevant existing unit tests (one test changed to account for better dex rotation heuristic). Added unit test to test deterministic output. Added unit performance test. By default run script merely validates that --multi-dex and --num-threads can be used together (fast). However, the test is configurable to perform performance test, over sets of generated classes. Change-Id: Ic2d11c422396e97171c2e6ceae9477113e261b8e Signed-off-by: Peter Jensen <jensenp@google.com>
* | | | Merge "Fix dx test 124-multidex-option-no-overflow"Benoit Lamarche2014-09-111-3/+3
|\ \ \ \
| * | | | Fix dx test 124-multidex-option-no-overflowBenoit Lamarche2014-09-111-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Thresholds for fields was too low for our new pessimistic overflow detection that takes the whole constant pool into account. Change-Id: If11a35329bf459fef54f538257a5dd22a30f99e7
* | | | | Merge "Fix dx test 113-old-style-inner-class"Benoit Lamarche2014-09-111-1/+1
|\ \ \ \ \
| * | | | | Fix dx test 113-old-style-inner-classBenoit Lamarche2014-09-111-1/+1
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | Test output was polluted by a javac warning. We're only interested in dx warnings. Change-Id: I2883670ff062b930de5dfd156bc6a98ba4534edf
* / / / / Fix dx test 118-find-usagesBenoit Lamarche2014-09-111-5/+5
|/ / / / | | | | | | | | | | | | | | | | | | | | Reference file format was obsolete. Change-Id: I3c2d4fe46baf0bbd6fa156e261d893cfb890d993
* | | | Fix dx test 127-merge-stressBenoit Lamarche2014-07-231-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | Check that dex files are valid using dexdump before merging them. Change-Id: Id1858fa194e12fae50a37af3d8906760bfcddd27
* | | | Renumber dx test multidex-option-overflow to 128.Yohann Roussel2014-07-213-0/+0
| | | | | | | | | | | | | | | | | | | | Because there were 2 tests 123. Change-Id: I8673a78d58e32283225ea83746a54f1e9b60cedd
* | | | Add DexMerge stress testBenoit Lamarche2014-07-164-0/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also add use of DexIndexOverflowException (cherry picked from commit f95ee7b39f09c13340387e5ae370b57589178b0f) Change-Id: Ia8592173cf84d9e2119c0a81bbcba90ba9222f64
* | | | Add tests about dx multidex options.Yohann Roussel2014-07-1619-0/+308
| |_|/ |/| | | | | | | | | | | | | | (cherry picked from commit fc30e016ca4dbd4224a693e2eb7600060e547d3a) Change-Id: Ibfc0a9b54244197b0044f995e3a221898c86ca3d
* | | Remove dx/tests/120-disable-extend-opsNarayan Kamath2014-03-114-118/+0
| |/ |/| | | | | | | | | Support for the target-api flag was removed in 2011. Change-Id: Id50c53f759d4e3a59f550dbeb6e733b68df58dd3
* | Transform incorrect invokevirtual ops to invokedirect.Narayan Kamath2014-03-115-0/+62
|/ | | | | | bug: 12370565 Change-Id: I75de311912d3e620f95fbac712e799e64622e4ab
* Added support for version 51 class files in dxdelphinemartin2013-05-1614-64/+200
| | | | | | | | If an invokedynamic is present, an exception is thrown. (cherry picked from commit 94629f2a31206637fc79535ffef1b223e9f02e30) Change-Id: I1922d4cf78465dfd2ac53f8694b7317a1d98016d
* Mechanical refactoring of dx into two parts.Jesse Wilson2013-04-304-27/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This splits off a new package, com.android.dex that contains code for parsing and modelling dex files. This code is usable both at build time (for compilation and analysis) and at runtime (for introspection). The original package, com.android.dx is the tool that compiles .class files into .dex files. That package also includes utilities for merging and querying dex files, all visible to the dx command line application. In a follow up change I'll move the new com.android.dex package into the libcore/ project, and configure build rules so that it's included in both dx.jar and core.jar. The core.jar will then be able to use it for annotation processing. Change-Id: I3c58cf87e728e4dda1925a0992c1ee7b8130e81a (cherry picked from commit bab4abb07335d162ecdb8091fc395cf84803a580) Conflicts: dx/junit-tests/com/android/dx/util/BitIntSetTest.java dx/junit-tests/com/android/dx/util/BitsTest.java dx/junit-tests/com/android/dx/util/IntListTest.java dx/junit-tests/com/android/dx/util/ListIntSetTest.java dx/src/com/android/dex/Dex.java dx/src/com/android/dex/TableOfContents.java dx/src/com/android/dx/annotations/AnnotationAccess.java dx/src/com/android/dx/command/Main.java dx/src/com/android/dx/dex/code/OutputFinisher.java dx/src/com/android/dx/dex/code/form/Form32s.java dx/src/com/android/dx/dex/code/form/Form33x.java dx/src/com/android/dx/dex/code/form/Form41c.java dx/src/com/android/dx/dex/code/form/Form52c.java dx/src/com/android/dx/gen/DexGenerator.java dx/src/com/android/dx/merge/DexMerger.java
* Correctly handle switches on values in a high registerBen Gruver2012-08-224-0/+1173
| | | | | | | | | | When dx generates a switch on a value in a high register, it prepends a move instruction, to move the value to a low register. However, this causes the switch data pseudo-instruction to use address of the move instruction as the base address of the switch targets, rather than the address of the switch instruction Change-Id: I0708d35ec3059c30221cd0a64f426244411d31ea
* Merge "Use 'dalvikvm' only to test dx." into dalvik-devJesse Wilson2011-05-045-18/+24
|\
| * Use 'dalvikvm' only to test dx.Jesse Wilson2011-03-185-18/+24
| | | | | | | | | | Change-Id: I1fca7ce23e9b3706d75580c06956d49d79614fe6 http://b/4090053
* | Bugfix for constant propagation of float/double division/modulo.jeffhao2011-04-294-0/+905
| | | | | | | | Change-Id: I2887749d9aa7739e79e4aac976957f5a422d2217
* | Combine CstUtf8 and CstString.Jesse Wilson2011-04-216-9/+9
| | | | | | | | | | | | | | | | | | | | The only benefit we were seeing is that one wrapped its toHuman in quotes, the other didn't. It was far too easy to use the wrong one. We had code defending against that in NameValuePair and CstArray. Change-Id: Ib2e6a1596b97decced37952d46e1831b7bcd0d5d
* | Various dx fixes to make it preserve locals and debug info.jeffhao2011-03-241-5/+5
| | | | | | | | | | | | | | | | | | | | The SCCP pass checks if a register has associated local info before attepting to prune branches or replace values with constants. Also, the register allocator reserves a register for each local in a method. This could be later improved by only reserving registers for the lengths of their lifetimes as specified by the local info table. Change-Id: I654ac014a9aac530f1db0db7d5cdef7535ff49bf
* | Add opcode-emission backward compatibility.Dan Bornstein2011-03-214-0/+118
|/ | | | | | | | | | | | | This makes it so that when you pass dx --target-api=N, where N is an API level representing Honeycomb or earlier, dx will not emit any of the new extended opcodes. N is currently baked into the code as 12 or larger being post-Honeycomb, but it is subject to change if there are more revs of the API under the Honeycomb umbrella (which wouldn't be surprising). Bug: 4094709 Change-Id: Iaf5177f179b22586bcf806ecb53de20b6e989777
* Add support for pre-dexed libraries to dx.Jesse Wilson2011-03-168-26/+120
| | | | | | http://b/4090053 Change-Id: Ifb8b9230939cb2a72a767128f79cbfbd042e95a6
* Don't emit multiple copies of annotations when merging dex files.Jesse Wilson2011-03-162-43/+29
| | | | | | | | | | | This change requires all annotations to be loaded into memory so they can be sorted. There does not appear to be a required order to the annotations in .dex files. Loading annotations also requires loading encoded values, which makes this into a large refactoring. Change-Id: Ib7e2656c595018be4e9936eb84a22f1c1de56750 http://b/4090053
* Fix for test case now that jumbo opcodes are on.jeffhao2011-03-031-9/+7
| | | | Change-Id: Iad2bde29a3e0898b564b8e2c695dd45d3a6e927f
* Changed dx register allocator to place more phis and reuse locals.jeffhao2011-02-241-4/+4
| | | | | | | | | | | This change makes the register allocator try to place all phis earlier, by using whichever register is most common among its sources and result. In addition, the code tries much harder to reuse registers originally reserved for locals if they are no longer live. This leads to fewer registers in many methods. Change-Id: I5f69320686184f784384f5cf3a1d9c97e44ec19d
* Retain annotations when merging dex files.Jesse Wilson2011-02-192-0/+65
| | | | | | | | | This change has one major limitation: it doesn't deduplicate equal annotation directories or annotation sets across dex files. That will result in unnecessarily large dex files. Change-Id: If63273d16eba1d989c6b5695d102b378d4047119 http://b/3447216
* Emit compact ouput .dex files.Jesse Wilson2011-02-161-0/+33
| | | | | Change-Id: I69ca23b53a542db7e7a18d819795e795bf0822c0 http://b/3447216
* Fix to allow SCCP to correctly propagate division and remainer ops.jeffhao2011-02-111-1/+1
| | | | | | Also updated expected values for the const collector test. Change-Id: Iedcf17d776c60cb6174f7a7c9f75be84d2c38020
* Updated expected outputs for some dx tests.jeffhao2011-02-073-111/+89
| | | | | | | | Recent changes in code generation caused the generated output to no longer match the expected results of these tests. They've now been updated properly. Change-Id: I223075e2b1ff297d37022d77de74304b084ca900
* Fix expected output.Dan Bornstein2011-02-074-17/+17
| | | | | | | | The expected output of these tests changed due to incidental (to the tests) changes in dx, in particular renaming the payload opcodes and simplifying some error output. Change-Id: Ia16cd484202a86b9ddab1ae4794a384b2ec53d9a
* Move opcode names into OpcodeInfo.Dan Bornstein2011-02-021-5/+5
| | | | | | | | | This also allowed me to remove the Instruction argument from the CodeReader visitor methods. Per previous discussion, this also gets rid of the redundant argument output in FindUsages. I can clean up CodeReader some more in a follow-up. Change-Id: I7a65e8d74498e201fd169cddde0d1f19d6f33f81
* Hook up CodeReader.Dan Bornstein2011-02-021-5/+5
| | | | | | | | This involved tweaking a lot of interfaces and a few bits of the implementation, and it could use at least one cleanup pass, but I think the basic structure is pretty reasonable. Change-Id: Ic49410aca479d54ceb837ee7e04bedd2ca0bcda9
* Add an undocumented --incremental option to dx.Jesse Wilson2011-01-185-3/+108
| | | | Change-Id: I48879b2f724e9b92c99c669803f9c8de01487327
* New tool merge two dex files into one.Jesse Wilson2011-01-0916-0/+440
| | | | | | | | | | | | | | | | | | This code isn't yet ready for general use, but I have booted a device using a core.jar from the product of a merge. In particular, I still need to better size the output dex. The motivation is to support incremental builds in dx. Given a "--incremental" flag, dx would create a dex file containing only those classes newer than the target .dex. Then it would merge that small .dex with the current .dex. Hopefully this yields a nice speedup over dexing everything. It would also be possible to use this to do parallel builds. We would manually partition the input files, dx them, and then merge the result together. Change-Id: I8997fb3c8bfe73b64ef38a7cb3d6456fbe799d0f
* Always dump blocks in label order.Dan Bornstein2010-11-016-435/+435
| | | | | | | 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
* Fix expected output of dx test 086.Dan Bornstein2010-10-281-76/+76
| | | | | | | It experienced both innocuous block order shift and changes to content due to the earlier constant value propagation fix. Change-Id: If97d9cc82e763e9bbd7c3a8ba834f2d994eb694b
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-16 16:22:47 +0000