[Webkit-unassigned] [Bug 162124] Unite op_get_by_id_with_this with op_get_by_id
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Sat Oct 8 14:53:17 PDT 2016
https://bugs.webkit.org/show_bug.cgi?id=162124
--- Comment #28 from Filip Pizlo <fpizlo at apple.com> ---
(In reply to comment #20)
> (In reply to comment #19)
> > Why would we do this?
>
> If I didn't miss any context *_with_this were created to solve the bug on
> (https://bugs.webkit.org/show_bug.cgi?id=147064). The current
> implementationis just a call to slow paths "operation*WithThis", meaning
> that we don't use IC or PIC on "super.foo" for example.
> Merging get_by_id_with_this with op_get_by_id we enable its optimization
> including IC and PIC. In terms of performance, now it means 20% faster over
> op_get_by_id_with_this version.
Then you should make get_by_id_with_this use inline caches.
You shouldn't change get_by_id.
>
> > It's definitely good for lower tiers that get_by_id does not take an extra
> > this operand. It's also easier to parse. I don't understand why we would
> > remove this optimization.
>
> I didn't understand why it is easier to parse.
> Also, About good parts of get_by_id does not take an extra this operand, do
> you mind explain me why? I can think that we use extra memory to store the
> this operand, which has a big impact because get_by_id is one of the most
> used op_codes.
Compiler analyses always have an O(E) component, where E is the number of data flow edges. One such analysis is the OSR likeness analysis in the DFG and FTL. It's a very expensive analysis and we don't want to make it worse. You're adding a useless "this" data flow edge to every property access. I don't think we want that.
I just want to be very clear: I'm strongly against uniting get_by_id with get_by_id_with_this. Please change your approach to making the unification happen at the PolymorphicAxcess/StructureStubInfo level and please keep these opcodes sepaate.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20161008/7cd93580/attachment.html>
More information about the webkit-unassigned
mailing list