Embedded constant pools.

src/ppc/lithium-codegen-ppc.cc

Index: src/ppc/lithium-codegen-ppc.cc
diff --git a/src/ppc/lithium-codegen-ppc.cc b/src/ppc/lithium-codegen-ppc.cc
index 443d8e706be47813f0b1210ee12accfa3661bb96..ec7860bcbd696c00f507db46a429783b5103c551 100644
--- a/src/ppc/lithium-codegen-ppc.cc
+++ b/src/ppc/lithium-codegen-ppc.cc
@@ -50,8 +50,15 @@ bool LCodeGen::GenerateCode() {
   // the frame (that is done in GeneratePrologue).
   FrameScope frame_scope(masm_, StackFrame::NONE);
 
-  return GeneratePrologue() && GenerateBody() && GenerateDeferredCode() &&
-         GenerateJumpTable() && GenerateSafepointTable();
+  bool rc = GeneratePrologue() && GenerateBody() && GenerateDeferredCode() &&
+            GenerateJumpTable() && GenerateSafepointTable();
+#ifdef DEBUG
+  if (!rc) {
+    // Avoid DCHECK(!is_linked()) failure in ~Label()

[rmcilroy, 2015/06/01 09:52:09]

Won't this cause issues in non-debug code if the label is getting deleted before
the constant pool is emitted?

[MTBrandyberry, 2015/06/01 21:01:30]

Not quite.  The label gets deleted upon destruction of the assembler object. 
The issue here is that the embedded constant pool label may be linked to in the
prologue, but never bound since this path aborts the compilation prior to
reaching GetCode (where the constant pool would have been emitted).

If there is a better way to work around  this, let me know.  It seems like the
labels used for deferred code generation could also run into this.  Perhaps the
tests just don't exercise that scenario?

[rmcilroy, 2015/06/02 13:57:21]

The more I think about it the less keen I am to be storing this as a label in
the constant pool builder object. Could you just do the same as on Arm instead
(getting the offset from the code object and adding that to the code target
address)? 

[MTBrandyberry, 2015/06/02 15:36:10]

Loading the offset from the code object is problematic on PPC due to the lack of
pc-relative addressing.

I disagree that this scenario or the builder's use of a label is inherently bad.
 As far as I can tell, it's no different than any other use of a label prior to
binding it.  If anything, the problem is that the Label destructor's DCHECK is
invalid for cases such as this where the compilation was aborted and the code
will be discarded.

[rmcilroy, 2015/06/02 16:40:12]

OK.
Ok. How about adding a masm()->AbortConstantPoolBuilding() (just for PPC) which
explicitly binds the label to make it obvious why this is happening (and avoid
emitting the constant pool when assembly failed, which seems like it might go
wrong).

[MTBrandyberry, 2015/06/02 16:55:31]

sgtm

+    masm()->EmitConstantPool();
+  }
+#endif
+  return rc;
 }