Experimental: initial simple support for registers in the virtual...

v8/src/virtual-frame-ia32.h

 // Copyright 2008 the V8 project authors. All rights reserved.
 // Redistribution and use in source and binary forms, with or without
 // modification, are permitted provided that the following conditions are
 // met:
 //
 //     * Redistributions of source code must retain the above copyright
 //       notice, this list of conditions and the following disclaimer.
 //     * Redistributions in binary form must reproduce the above
 //       copyright notice, this list of conditions and the following
 //       disclaimer in the documentation and/or other materials provided
@@ skipping 23 matching lines @@
 
 // -------------------------------------------------------------------------
 // Virtual frame elements
 //
 // The internal elements of the virtual frames.  Elements are (currently) of
 // only one kind, in-memory.  Their actual location is given by their
 // position in the virtual frame.
 
 class FrameElement BASE_EMBEDDED {
  public:
-  enum Type { MEMORY, CONSTANT, LAST_TYPE = CONSTANT };
+  enum Type { MEMORY, REGISTER, CONSTANT, LAST_TYPE = CONSTANT };
 
   FrameElement() : type_(MEMORY) {}
 
+  explicit FrameElement(Register reg) : type_(REGISTER | kDirtyBit) {
+    data_.reg_ = reg;
+  }
+
   explicit FrameElement(Handle<Object> value) : type_(CONSTANT | kDirtyBit) {
     data_.handle_ = value.location();
   }
 
-  Type type() const { return static_cast<Type>(type_ & kTypeMask); }
-
   bool is_dirty() const {
     return (type_ & kDirtyBit) != 0;
   }
 
   void set_dirty() {
     ASSERT(type() != MEMORY);
     type_ = type_ | kDirtyBit;
   }
 
   void clear_dirty() {
     ASSERT(type() != MEMORY);
     type_ = type_ & ~kDirtyBit;
   }
 
+  bool is_spilled() const { return type() == MEMORY; }
+  bool is_register() const { return type() == REGISTER; }
+  bool is_constant() const { return type() == CONSTANT; }

[William Hesse, 2008/11/19 15:05:36]

If is_spilled() is only true when type is MEMORY, then
spilling a constant by marking it non-dirty won't be enough - we will have to
forget the fact that it is a constant.
But maybe that is what you mean by spilling - it is needed for
merging, but not for branching or function calls.
Will we have different terms for "everthing non-dirty, all registers free" and
"everything non-dirty, no info at all"?

[iposva, 2008/11/20 05:49:35]

Should there be an is_synched() accessor to make the distinction clearer to the
reader. I am not sure though if it would be useful in the code.

[Kevin Millikin (Chromium), 2008/11/20 08:28:03]

Maybe it's best to rename is_spilled to something more obvious.  is_in_memory
seems accurate but I don't like reading it.

+
+  Register reg() const {
+    ASSERT(type() == REGISTER);
+    return data_.reg_;
+  }
+
   Handle<Object> handle() const {
     ASSERT(type() == CONSTANT);
     return Handle<Object>(data_.handle_);
   }
 
  private:

[iposva, 2008/11/20 05:49:35]

C++ style guide suggests this order:
- Typedefs and Enums
- Constants
- Constructors
- Destructor
- Methods, including static methods
- Data Members, including static data members

[Kevin Millikin (Chromium), 2008/11/20 08:28:03]

It seems like we often have data members first in our code base (at least
private ones).  But since this is new code, there is no reason not to stick to
the style guide.  I'll change it.

   static const int kDirtyBit = 1 << 8;

[iposva, 2008/11/20 05:49:35]

As I said in my other comments. You probably really want to use the BitField
template here.

   static const int kTypeMask = kDirtyBit - 1;
 
-  STATIC_ASSERT((kDirtyBit > LAST_TYPE));
+  STATIC_ASSERT(kDirtyBit > LAST_TYPE);
 
   // The element's type and a dirty bit.  The dirty bit can be cleared
   // for non-memory elements to indicate that the element agrees with
   // the value in memory in the actual frame.
   int type_;
 
   union {
+    Register reg_;
     Object** handle_;
   } data_;
+
+  Type type() const { return static_cast<Type>(type_ & kTypeMask); }

[William Hesse, 2008/11/19 15:05:36]

Will code constructors only be able to access the type of "Result", to make
decisions on?  That makes sense, I guess.

[Kevin Millikin (Chromium), 2008/11/20 08:28:03]

I decided not to expose the type (in fact, the enum should probably be private
too).  Internally, we might have a lot of different "types" for administrative
purposes (eg, constant vs. source constant) that the clients of the frame don't
care about.

The place where types might be better than predicates is if clients want to
write a switch instead of nested if-then-else.  But that code is brittle to
addition of types anyway....

 };
 
 
 // -------------------------------------------------------------------------
 // Virtual frames
 //
 // The virtual frame is an abstraction of the physical stack frame.  It
 // encapsulates the parameters, frame-allocated locals, and the expression
 // stack.  It supports push/pop operations on the expression stack, as well
 // as random access to the expression stack elements, locals, and
@@ skipping 155 matching lines @@
 
   // The index of the base of the expression stack.
   int expression_base_index() const { return local0_index() + local_count_; }
 
   // Convert a frame index into a frame pointer relative offset into the
   // actual stack.
   int fp_relative(int index) const {
     return (frame_pointer_ - index) * kPointerSize;
   }
 
+  // Sync the element at a particular index---write it to memory if
+  // necessary, but do not free any associated register or forget its value
+  // if constant.  Space should have already been allocated in the actual
+  // frame for all the elements below this one (at least).

[iposva, 2008/11/20 05:49:35]

Not just the space should be allocated, but all the elements should be on the
stack at least at GC points.

[Kevin Millikin (Chromium), 2008/11/20 08:28:03]

I agree that "sync" vs. "spill" is fuzzy.  The point is that we sometimes want
to allocate space in the frame to spill a value (in case we later need to spill
it), without actually spilling it (eg, without forgetting that it is a constant
or in a particular register).

But, as you say, we have to put something safe for GC in that slot so it makes
sense to put the real value there and avoid a move later in the event of a spill
before the frame element is changed again.

Thus "sync"---to make the value in memory agree with the frame but not change
the frame value.

It will likely only be used for allocating space for a spill, so changing the
name probably removes confusion (I just can't think of a better name right now).

+  void SyncElementAt(int index);
+
+  // Spill the element at a particular index---write it to memory if
+  // necessary, free any associated register, and forget its value if
+  // constant.  Space should have already been allocated in the actual frame
+  // for all the elements below this one (at least).
+  void SpillElementAt(int index);

[William Hesse, 2008/11/19 15:05:36]

OK, this answers my question about different terms for spill and sync.

+
   // Spill the topmost elements of the frame to memory (eg, they are the
   // arguments to a call) and all registers.
   void PrepareForCall(int count);
 };
 
 
 } }  // namespace v8::internal
 
 #endif  // V8_VIRTUAL_FRAME_IA32_H_