Embedded constant pools.

src/ppc/lithium-codegen-ppc.cc

 // Copyright 2014 the V8 project authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "src/v8.h"
 
 #include "src/base/bits.h"
 #include "src/code-factory.h"
 #include "src/code-stubs.h"
 #include "src/cpu-profiler.h"
@@ skipping 32 matching lines @@
 bool LCodeGen::GenerateCode() {
   LPhase phase("Z_Code generation", chunk());
   DCHECK(is_unused());
   status_ = GENERATING;
 
   // Open a frame scope to indicate that there is a frame on the stack.  The
   // NONE indicates that the scope shouldn't actually generate code to set up
   // 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;
 }
 
 
 void LCodeGen::FinishCode(Handle<Code> code) {
   DCHECK(is_done());
   code->set_stack_slots(GetStackSlotCount());
   code->set_safepoint_table_offset(safepoints_.GetCodeOffset());
   PopulateDeoptimizationData(code);
 }
 
@@ skipping 6149 matching lines @@
   __ Push(scope_info);
   __ push(ToRegister(instr->function()));
   CallRuntime(Runtime::kPushBlockContext, 2, instr);
   RecordSafepoint(Safepoint::kNoLazyDeopt);
 }
 
 
 #undef __
 }
 }  // namespace v8::internal