Le mercredi 7 décembre 2016 12:42:55 UTC-5, Caitlin Potter a écrit : > > 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.
