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
diff --git a/compiler/optimizing/nodes.h b/compiler/optimizing/nodes.h
index e40361e..72521fd 100644
--- a/compiler/optimizing/nodes.h
+++ b/compiler/optimizing/nodes.h
@@ -6650,6 +6650,14 @@
// still considered live.
static void RemoveConstructorFences(HInstruction* instruction);
+ // Check if this constructor fence is protecting
+ // an HNewInstance or HNewArray that is also the immediate
+ // predecessor of `this`.
+ //
+ // Returns the associated HNewArray or HNewInstance,
+ // or null otherwise.
+ HInstruction* GetAssociatedAllocation();
+
DECLARE_INSTRUCTION(ConstructorFence);
private: