Reviewers: iposva, Message: This is annoyingly subtle behavior.
It's convenient to have local names for frame elements. It's not safe to declare top a FrameElement&, because something could cause the list backing store to be resized. We will need to identify the functions that can change an arbitrary frame element, then carefully audit the places where we use a local name for a copy of a frame element to make sure that it is safe. Description: A register allocation bugfix. The function that prepares a virtual frame slot for writing (in order to preserve the copy-on-write semantics of aliased frame elements) can allocate registers, which may spill one from the frame. If we're unlucky, the spilled register can be the source register for the frame element write. In that case, ensure we do the write from memory. Please review this at http://codereview.chromium.org/115125 SVN Base: http://v8.googlecode.com/svn/branches/bleeding_edge/ Affected files: M src/ia32/virtual-frame-ia32.cc Index: src/ia32/virtual-frame-ia32.cc =================================================================== --- src/ia32/virtual-frame-ia32.cc (revision 1900) +++ src/ia32/virtual-frame-ia32.cc (working copy) @@ -623,6 +623,12 @@ InvalidateFrameSlotAt(index); + // InvalidateFrameSlotAt can potentially change any frame element, due + // to spilling registers to allocate temporaries in order to preserve + // the copy-on-write semantics of aliased elements. Reload top from + // the frame. + top = elements_[top_index]; + if (top.is_copy()) { // There are two cases based on the relative positions of the // stored-to slot and the backing slot of the top element. --~--~---------~--~----~------------~-------~--~----~ v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev -~----------~----~----~----~------~----~------~--~---
