https://codereview.chromium.org/1272673003/diff/150001/src/parser.cc
File src/parser.cc (right):

https://codereview.chromium.org/1272673003/diff/150001/src/parser.cc#newcode4415
src/parser.cc:4415: // for (var $argument_index = $rest_index;
On 2015/09/01 03:09:10, Benedikt Meurer wrote:
I guess there was some discussion about this desugaring; so do we have
any plans
how to make this work with inlining? esp. inlining in TurboFan?

I don't think there are plans per se (but you might have seen there was
some TF code previously for this, not sure how complete it was in terms
of inlining).

There are at least some ideas about how the runtime call could be
changed into something relatively quick. The spec'd algorithm uses
CreateDataProperty(O, P, V) to add the element to the array. For rest
parameters, we can make a lot of assumptions which lend themselves well
to inlining:

- the rest array's own "length" property is always writable, never
configurable
- the rest array is always extensible
- the rest array's own indexed properties are always writable and
configurable (they aren't present until the rest parameter algorithm
sets them up)

Based on this, yes, the current implementation probably isn't doing the
right thing, but it's pretty close.

I guess there are also statistical guesses about the size of the array
to allocate, and whether or not to perform the loop at all, after a bit
of profiling. But maybe compiler-folks are better for talking about that
stuff.

https://codereview.chromium.org/1272673003/diff/150001/src/parser.cc#newcode4425
src/parser.cc:4425: auto var = parameters.scope->parameter(i);
On 2015/09/01 03:09:10, Benedikt Meurer wrote:
Nit: Wow, this heavy autofication. I'm not sure what the convention
for the
parser is, but I'd prefer to reduce the use of auto, esp. when it's
used in
place of a pointer type.

My feeling is that it's alright for AST nodes (because of the
`New<NodeType>` methods providing all the missing info), which is the
bulk of the auto use. If folks want explicit typenames used everywhere,
we can do that too.

How important is this, given that the majority of this is AST nodes?

https://codereview.chromium.org/1272673003/

--
--
v8-dev mailing list
v8-dev@googlegroups.com
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 v8-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to