[v8-dev] Implementing inline caches for GenericBinaryOpStub. ... (issue551093)

Reviewers: Kevin Millikin, Mads Ager, Description: Implementing inline caches for GenericBinaryOpStub. There are 3 fast cases: HeapNumber operands, String operands and Object operands. This CL implements it for ia32 only. Please review this at http://codereview.chromium.org/551093 SVN Base: htt

[v8-dev] Re: Implementing inline caches for GenericBinaryOpStub. ... (issue551093)

http://codereview.chromium.org/551093 -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev

[v8-dev] Re: Implementing inline caches for GenericBinaryOpStub. ... (issue551093)

I have addressed all the comments. Now I will split this CL into two as Mads suggested: one dealing with registers/smis improvements, another dealing with ICs. http://codereview.chromium.org/551093/diff/1/3 File src/ia32/codegen-ia32.cc (right): http://codereview.chromium.org/551093/diff/1/3

[v8-dev] Re: Removing BinaryOpIC::Clear. This method relied on some less-than-obvious hack... (issue1623005)

ARM codegen currently does not have binary op ICs in trunk. My change got reverted when it broke debug tests. The funny thing is: BinaryOpIC::Clear was the reason. I am re-submitting ARM change today with this issue fixed. Vlad On Thu, Apr 8, 2010 at 5:36 PM, wrote: > LGTM, thanks! > > Isn't

[v8-dev] Re: Re-submitting binary op ICs for ARM. Does not break debug tests (issue1629008)

That and a change in BinaryOpIC::GetTypeInfo that also have been breaking debug tests. On Thu, Apr 8, 2010 at 7:12 PM, wrote: > > LGTM, I suppose the only change to the previous submit is the removal of the > clearing on GC? > > http://codereview.chromium.org/1629008/show -- v8-dev mailing list

[v8-dev] Re: Re-submitting binary op ICs for ARM. Does not break debug tests (issue1629008)

question. Vlad On Thu, Apr 8, 2010 at 7:25 PM, Mads Sig Ager wrote: > Can you quickly explain why that assert is triggered on ARM and not on > the other platforms? > > Thanks,    -- Mads > > On Thu, Apr 8, 2010 at 5:17 PM, Vladislav Kaznacheev > wrote: >> That

[v8-dev] Re: Extend CallIC to support non-constant names.... (issue2280007)

Summarizing the chat we had with Mads: 1. Doesn't this mean that we will always enter the runtime system for > calling > functions in arrays: a[0]()? This used to be a KeyedLoadIC followed by a > call > which is pretty fast. We should make sure that this is still fast. > This has been my oversigh

[v8-dev] Re: Fix charCodeAt custom call generator.... (issue2478003)

OK. BTW, similar change on x64 broke something, so I know it is not that simple. Vlad On Wed, Jun 2, 2010 at 6:36 PM, wrote: > Vlad, > > Thanks a lot for spotting this! > > Unfortunately, you can't just overwrite the index register. The contract of > the > generator is to preserve it. It may

[v8-dev] Re: Extracting relocation info from the code object.... (issue2812041)

Fixed before submitting. Thanks, Vlad On Mon, Jul 5, 2010 at 3:25 PM, wrote: > There is a lint error on objects.h. > > > http://codereview.chromium.org/2812041/show > -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev

[v8-dev] Kaznacheev is sick at home, will read emails periodically EOM

-- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev

[v8-dev] Re: Dynamically determine optimal instance size.... (issue3329019)

Thanks for the comments! We had a long discussion with Vitaly on how to proceed, and here is what we came up with (let me know if you find anything of the following stupid): - Updating the slack estimation on every map transition is too fragile and does not provide any performance benefit. I will