Hi Caitlin, As I understand it, the main reason that type feedback slots are allocated during ast numbering is that it is important that all the compilers agree on which slots represent which operations. In the world of Ignition+Turbofan this isn't such a big problem since only Ignition would visit the AST and burns in the type feedback slots into the bytecode which is used when optimizing through Turbofan.
However, we currently allocate the TypeFeedback vector after parsing but before bytecode generation, and we need to know the number of slots when allocating the vector, so we can't allocate new slots after this point. Also, I think we should keep all type feedback slot allocation in one place, and since it needs to be during ast-numbering for FCG / Crankshaft, I'd prefer we didn't do any special-case allocations in the bytecode generator. Maybe we can reevaluate this and move all the allocation to the bytecode generator once the other compilers are deprecated. Cheers, Ross On 7 December 2016 at 18:42, Caitlin Potter <[email protected]> wrote: > 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. > -- -- 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.
