| 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
|