79d8fa7c52c1810d4618c9bd1d43994be5abb53d |
|
18-Apr-2017 |
Igor Murashkin <iam@google.com> |
optimizing: Build HConstructorFence for HNewArray/HNewInstance nodes Also fixes: * LSE, code_sinking to keep optimizing new-instance if it did so before * Various tests to expect constructor fences after new-instance Sidenote: new-instance String does not get a ConstructorFence; the special StringFactory calls are assumed to be self-fencing. Metric changes on go/lem: * CodeSize -0.262% in ART-Compile (ARMv8) * RunTime -0.747% for all (linux-armv8) (No changes expected to x86, constructor fences are no-op). The RunTime regression is temporary until art_quick_alloc_* entrypoints have their DMBs removed in a follow up CL. Test: art/test.py Bug: 36656456 Change-Id: I6a936a6e51c623e1c6b5b22eee5c3c72bebbed35
|
d01745ef88bfd25df574a885d90a1a7785db5f5b |
|
06-Apr-2017 |
Igor Murashkin <iam@google.com> |
optimizing: constructor fence redundancy elimination - remove dmb after LSE Part one of a few upcoming CLs to optimize constructor fences. This improves load-store-elimination; all singleton objects that are not returned will have their associated constructor fence removed. If the allocation is removed, so is the fence. Even if allocation is not removed, fences can sometimes be removed. This change is enabled by tracking the "this" object associated with the constructor fence as an input. Fence inputs are considered weak; they do not keep the "this" object alive; if the instructions for "this" are all deleted, the fence can also be deleted. Bug: 36656456 Test: art/test.py --host && art/test.py --target Change-Id: I05659ab07e20d6e2ecd4be051b722726776f4ab1
|
f8b3b8bc37fb04d8ae113ae6bfcf4de2f5a700d4 |
|
04-Feb-2016 |
Vladimir Marko <vmarko@google.com> |
Try to substitute constructor chains for IPUTs. Match a constructor chain where each constructor either forwards some or all of its arguments to the next (i.e. superclass constructor or a constructor in the same class) and may pass extra zeros (of any type, including null), followed by any number of IPUTs on "this", storing either arguments or zeros, until we reach the contructor of java.lang.Object. When collecting IPUTs from the constructor chain, remove any IPUTs that store the same field as an IPUT that comes later. This is safe in this case even if those IPUTs store volatile fields because the uninitialized object reference wasn't allowed to escape yet. Also remove any IPUTs that store zero values as the allocated object is already zero initialized. (cherry picked from commit 354efa6cdf558b2331e8fec539893fa51763806e) Change-Id: I691e3b82e550e7a3272ce6a81647c7fcd02c01b1
|
354efa6cdf558b2331e8fec539893fa51763806e |
|
04-Feb-2016 |
Vladimir Marko <vmarko@google.com> |
Try to substitute constructor chains for IPUTs. Match a constructor chain where each constructor either forwards some or all of its arguments to the next (i.e. superclass constructor or a constructor in the same class) and may pass extra zeros (of any type, including null), followed by any number of IPUTs on "this", storing either arguments or zeros, until we reach the contructor of java.lang.Object. When collecting IPUTs from the constructor chain, remove any IPUTs that store the same field as an IPUT that comes later. This is safe in this case even if those IPUTs store volatile fields because the uninitialized object reference wasn't allowed to escape yet. Also remove any IPUTs that store zero values as the allocated object is already zero initialized. Change-Id: If93022310bf04fe38ee741665ac4a65d4c2bb25f
|
0d11ffe0d59170903695b94c9af8bbadad59ebfe |
|
02-Feb-2016 |
Vladimir Marko <vmarko@google.com> |
Optimizing: Do not depend on sharpening in test 569. The sharpening may or may not remove the ArtMethod* parameter, so the test must not depend on its absence. This fixes the test 569 checker test on mips/mips64. Change-Id: Ibee88d3602778006558caf33cf69e7c419918699
|
be10e8e99a78caae01fb65769218800d465144ae |
|
22-Jan-2016 |
Vladimir Marko <vmarko@google.com> |
Optimizing: Try pattern substitution when we cannot inline. Change-Id: I7c01f4494bac8498accc0f087044ec509fee4c98
|