<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - op_get_by_id_with_this should use inline caching"
href="https://bugs.webkit.org/show_bug.cgi?id=162124#c30">Comment # 30</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - op_get_by_id_with_this should use inline caching"
href="https://bugs.webkit.org/show_bug.cgi?id=162124">bug 162124</a>
from <span class="vcard"><a class="email" href="mailto:ticaiolima@gmail.com" title="Caio Lima <ticaiolima@gmail.com>"> <span class="fn">Caio Lima</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=162124#c28">comment #28</a>)
<span class="quote">> (In reply to <a href="show_bug.cgi?id=162124#c20">comment #20</a>)
> > (In reply to <a href="show_bug.cgi?id=162124#c19">comment #19</a>)
> > > Why would we do this?
> >
> > If I didn't miss any context *_with_this were created to solve the bug on
> > (<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - Getter and setter on super are called with wrong "this" object"
href="show_bug.cgi?id=147064">https://bugs.webkit.org/show_bug.cgi?id=147064</a>). 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. </span >
Thank you for this explanation. I implemented a logic to avoid create an edge if ```base == this``` just thinking in memory usage, but it is interesting know that it also affects analyses performance.
<span class="quote">> 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.</span >
Agreed. I don't like the idea of an operand for ```this``` in all property access on op_get_by_id since it is useless ~95% of time.
(In reply to <a href="show_bug.cgi?id=162124#c29">comment #29</a>)
<span class="quote">> I agree with Fil. I think we should just abstract the IC machinery to allow
> for get_by_id_with_this semantics. It probably requires modifying
> PolymorphicAccess, a new IC generator for the baseline, and proper handling
> in the DFG/FTL. I suspect you'll be able to abstract certain code in the
> DFG/FTL to handle both nodes. Also, I suspect the heart of the work you
> already did was in PolymorphicAccess and StructureStubInfo, so all of that
> code should not really be changed regardless of if the opcodes are united or
> not.</span >
Cool. I am going to work on that.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>