Hi, So as some of you have seen, I’ve recently refactored some code to desugar GetIterator() in the BytecodeGenerator rather than in the AST. The primary reason for doing this is that it’s much easier to read and understand this desugaring in the BytecodeGenerator rather than by building an AST and setting properties of the AST to indicate what I’m trying to do. While generating appropriate bytecode for this spec operation is much more straight forward in the BytecodeGenerator, a new AST node just to hold type feedback slots is not ideal.
What I’d like to happen, is to have type feedback slots allocated by the BytecodeGenerator as needed. This would allow removing the GetIterator AST node, and replace it with a helper like BuildGetIterator(), BuildIteratorStep(), etc, and generally clean up this whole machine. Allocating feedback slots during bytecode generation would also greatly simplify desugaring destructuring binding/assignment from within the BytecodeGenerator, which I expect would provide a lot of cleanup and simplification. It would also allow the removal of weird “special” AST nodes like GetIterator, which would be fantastic. So my question is, are there any strict constraints which require us to reserve feedback slots during the AstNumberingVisitor pass, and before generating bytecode? And if there are, does it seem possible to mitigate/remove them for the purposes of Ignition? -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
