[turbofan] optimize redundant moves around splinter sites

src/compiler/register-allocator.h

 // 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.
 
 #ifndef V8_REGISTER_ALLOCATOR_H_
 #define V8_REGISTER_ALLOCATOR_H_
 
 #include "src/compiler/instruction.h"
 #include "src/ostreams.h"
 #include "src/register-configuration.h"
@@ skipping 755 matching lines @@
   bool ExistsUseWithoutDefinition();
 
   void MarkAllocated(RegisterKind kind, int index);
 
   PhiMapValue* InitializePhiMap(const InstructionBlock* block,
                                 PhiInstruction* phi);
   PhiMapValue* GetPhiMapValueFor(TopLevelLiveRange* top_range);
   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();
 
   Zone* const allocation_zone_;
   Frame* const frame_;
   InstructionSequence* const code_;
   const char* const debug_name_;
   const RegisterConfiguration* const config_;
   PhiMap phi_map_;
   ZoneVector<int> allocatable_codes_;
   ZoneVector<int> allocatable_double_codes_;
   ZoneVector<BitVector*> live_in_sets_;
   ZoneVector<BitVector*> live_out_sets_;
   ZoneVector<TopLevelLiveRange*> live_ranges_;
   ZoneVector<TopLevelLiveRange*> fixed_live_ranges_;
   ZoneVector<TopLevelLiveRange*> fixed_double_live_ranges_;
   ZoneVector<SpillRange*> spill_ranges_;
   DelayedReferences delayed_references_;
   BitVector* assigned_registers_;
   BitVector* assigned_double_registers_;
   int virtual_register_count_;
 
   DISALLOW_COPY_AND_ASSIGN(RegisterAllocationData);
 };
 
 
+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);
 
   // Phase 1 : insert moves to account for fixed register operands.
   void MeetRegisterConstraints();
 
   // Phase 2: deconstruct SSA by inserting moves in successors and the headers
   // of blocks containing phis.
   void ResolvePhis();
@@ skipping 297 matching lines @@
   RegisterAllocationData* const data_;
 
   DISALLOW_COPY_AND_ASSIGN(LiveRangeConnector);
 };
 
 }  // namespace compiler
 }  // namespace internal
 }  // namespace v8
 
 #endif  // V8_REGISTER_ALLOCATOR_H_