Indeed. We need to kill FCG+CS first. I was wondering about the same for ToBoolean feedback in Ignition, where only Ignition knows whether it really needs a slot.
-- Benedikt 'Ross McIlroy' via v8-dev <[email protected]> schrieb am Mi., 7. Dez. 2016, 19:39: > 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. > -- -- 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.
