On Fri, Jan 14, 2011 at 11:52 AM, Kevin Millikin <[email protected]> wrote:
> I'm a little concerned about this.  (I just glanced at this, so maybe I'm
> missing something about the approach.)
> We already have inlining of JS functions, and we have %_ functions that get
> expanded inline into assembly code.  Couldn't you achieve much the same
> thing by implementing %_StringCharCodeAt and ensuring that StringCharCodeAt
> is able to be hit by inlining?

StringCharCodeAt (String.prototype.charCodeAt) is required to be more
generic by the spec (i.e. you can apply it to any object providing any
index, so it must do conversions sometimes). Even the fastest
implementation of this generic logic will be slower than a specialized
function that only takes strings and small integers. In particular
it's technically easier to make a specialized approach more GVN
friendly. That said, I do plan to use this new instruction to
implement %_StringCharCodeAt to support all the other places in our
standard library.


Thanks,
Vitaly

> On Thu, Jan 13, 2011 at 3:18 PM, <[email protected]> wrote:
>>
>> Reviewers: fschneider,
>>
>> Description:
>> Support StringCharCodeAt in hydrogen/lithium.
>>
>> Please review this at http://codereview.chromium.org/6304001/
>>
>> Affected files:
>>  M src/ast.cc
>>  M src/hydrogen-instructions.h
>>  M src/hydrogen.h
>>  M src/hydrogen.cc
>>  M src/ia32/lithium-codegen-ia32.h
>>  M src/ia32/lithium-codegen-ia32.cc
>>  M src/ia32/lithium-ia32.h
>>  M src/ia32/lithium-ia32.cc
>>  M src/objects-printer.cc
>>  M src/objects.h
>>
>>
>> --
>> v8-dev mailing list
>> [email protected]
>> http://groups.google.com/group/v8-dev
>
> --
> v8-dev mailing list
> [email protected]
> http://groups.google.com/group/v8-dev

-- 
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev

Reply via email to