[turbofan] optimize redundant moves around splinter sites

src/compiler/register-allocator.h

Index: src/compiler/register-allocator.h
diff --git a/src/compiler/register-allocator.h b/src/compiler/register-allocator.h
index a7a1f0073bd333f479f8f95c0d04470481c0822e..2a12b252d8222dacf1904477fbcf6f46250db25e 100644
--- a/src/compiler/register-allocator.h
+++ b/src/compiler/register-allocator.h
@@ -773,13 +773,6 @@ class RegisterAllocationData final : public ZoneObject {
   PhiMapValue* GetPhiMapValueFor(int virtual_register);
   bool IsBlockBoundary(LifetimePosition pos) const;
 
-  void Print(const InstructionSequence* instructionSequence);
-  void Print(const Instruction* instruction);
-  void Print(const LiveRange* range, bool with_children = false);
-  void Print(const InstructionOperand& op);
-  void Print(const MoveOperands* move);
-  void Print(const SpillRange* spill_range);
-
  private:
   int GetNextLiveRangeId();
 
@@ -806,6 +799,16 @@ class RegisterAllocationData final : public ZoneObject {
 };
 
 
+void Print(const RegisterConfiguration* config,
+           const InstructionSequence* instructionSequence);
+void Print(const RegisterConfiguration* config, const Instruction* instruction);
+void Print(const RegisterConfiguration* config, const LiveRange* range,
+           bool with_children = false);
+void Print(const RegisterConfiguration* config, const InstructionOperand& op);
+void Print(const RegisterConfiguration* config, const MoveOperands* move);
+void Print(const RegisterConfiguration* config, const SpillRange* spill_range);

[Jarin, 2015/10/29 07:37:25]

Why did you move the printing out of the class? We generally do not like global
functions.

[Mircea Trofin, 2015/10/29 14:14:40]

I needed to visualize a few things (InstructionSequence, MoveOperands) in the
move optimization unit tests, 
where we don't have a RegisterAllocationData. All that I really need for the
prints is the RegisterConfiguration.

I didn't want to teach RegisterConfiguration about all these other concepts, and
I also didn't want to teach 
the rest of the model about RegisterConfiguration.

I think printing/diagnostics needs a cleanup - we have printf, operator<<, and
now these Print (regardless where
they live). I think the javascript object model also has some mechanism. I'd
want to take a shot at it, but once
the higher priority items clear up. Would it be OK if we live the Prints here
for now - they help with the unittest 
scenario I mentioned?

[Jarin, 2015/10/29 14:32:13]

I understand, but why can't you move the printing into the class that it is
printing? That is generally what the JavaScript objects are doing.

In any case, could we do the printing in a separate CL? It seems to be quite
unrelated to the title of the CL.
I suppose this sort of answers the question above, but I think it is ok to teach
the rest of the model. 
 
Hmm, I am really worried that it will stay and I would like to avoid another way
of printing (and also polluting the namespace with globals). 

We know too well that printing is a mess, and I do not believe that introducing
yet another way solves anything. A year ago we had a big push towards using
streams and most team members (including me) now think it was a mistake. You
would have hard time convincing anyone about a new way. I think you might have
some success to convince people about undoing the stream stuff (because it sucks
for bunch of reasons, most notably for debugging, but also for formatting
integers and such).

+
+
 class ConstraintBuilder final : public ZoneObject {
  public:
   explicit ConstraintBuilder(RegisterAllocationData* data);