I agree that the bailout is ugly. It's there to avoid overriding the default implementation of VisitStatements and to get everything to work, but I will clean it up. One neat thing is that I've discovered all the places where we were generating dead code, because unreachable generated code has no current frame. In some cases, the dead code we generated was actually completely meaningless, so it's a good thing it was dead.
On Tue, Oct 28, 2008 at 12:16 PM, Kasper Lund <[EMAIL PROTECTED]> wrote: > To me, this looks like a good first step. I'm not particularly fond of > the frame_ == NULL bailout checks when visiting statements, and I > think it might make sense to split out the virtual frame abstraction > into its own set of files. I'd like to hear Ivan's opinion on the > direction of the change... > > On Mon, Oct 27, 2008 at 5:16 PM, <[EMAIL PROTECTED]> wrote: > > Reviewers: iposva, Kasper Lund, > > > > Description: > > Introduce the "JumpTarget", an abstraction of a label and an expected > > virtual frame layout at that label. This supports merging control > > flow while performing single-pass code generation directly from the > > AST. > > > > The first time control flow reaches a jump target (eg, by branching or > > jumping, or by binding it in a fall-through position), the expected > > frame is set as a clone of the current frame. When control flow > > subsequently reaches the jump target (eg, by branching, jumping, or > > binding), code will be emitted before the control transfer or > > fall-through to merge the current frame to the expected frame. > > > > This imposes the invariant that control flow must have reached a jump > > target somehow before the target is bound. Eg, we cannot compile the > > body of a loop (a jump target) before control flow reaches it (thus, > > the tests for 'for' and 'while' loops are compiled at the top rather > > than the bottom). > > > > Currently, since the virtual frame has no real state and is no > > different from the physical frame, there is never any code emitted to > > merge frames. Instead, we assert that the expression stack height is > > the same along both branches. > > > > Please review this at http://codereview.chromium.org/7862 > > > > SVN Base: http://v8.googlecode.com/svn/branches/bleeding_edge/ > > > > Affected files: > > M src/assembler.h > > M src/ast.h > > M src/ast.cc > > M src/codegen-ia32.h > > M src/codegen-ia32.cc > > M src/codegen.cc > > M src/globals.h > > M src/macro-assembler-ia32.h > > M src/macro-assembler-ia32.cc > > M src/parser.cc > > > > > > > --~--~---------~--~----~------------~-------~--~----~ v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev -~----------~----~----~----~------~----~------~--~---
