Alright, works for me. > On Dec 7, 2016, at 2:48 PM, Benedikt Meurer <[email protected]> wrote: > > 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] > <mailto:[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] > <mailto:[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] <mailto:[email protected]> > http://groups.google.com/group/v8-dev <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] > <mailto:v8-dev%[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > -- > -- > v8-dev mailing list > [email protected] <mailto:[email protected]> > http://groups.google.com/group/v8-dev <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] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev <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] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <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.
