On Fri, Jan 14, 2011 at 3:09 PM, Vyacheslav Egorov <[email protected]> wrote: >> Even the fastest implementation of this generic logic will be slower than a >> specialized >> function that only takes strings and small integers. > > If we teach hydrogen to inline it and then specialize inlined code > based on type feedback gathered for outer function we can actually > achieve the same boost. But this solution will be _way_ more general > then a special case covering only single function.
Guys, these strings functions (and some math functions) are already very special, because we rarely hit their real spec conforming bodies from the standard library JS files. Instead they have custom call IC stubs. They are already special cased in the hydrogen builder because we avoid calling them as constant functions and use their custom IC stubs instead. The motivation behind this patch is that when this custom stub is small we can benefit from further inlining (as we do with Math functions). Now as Slava says it would be really be nice to drop all the custom crap and infer the fast special versions based on the full bodies of these functions and the type feedback, and then do inlining. I definitely agree with that. It's just that I find it technically significantly more difficult. Thanks, Vitaly > On Fri, Jan 14, 2011 at 1:04 PM, Vitaly Repeshko <[email protected]> wrote: >> 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 >> > > -- > 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
