Tomorrow, I will send you the change list that enables stack checks in
loops. (I am told it should be as easy as commenting out one line that
disables stack checks for asm.js in AstGraphBuilder::VisitIterationBody and
then benchmarking with Embenchen.)

On Thu, Aug 6, 2015 at 6:10 PM, Mircea Trofin <[email protected]> wrote:

> On the perf topic, it'd be good to feed in the mix some benchmarks that
> validate that, indeed, spilling in deferred blocks brings value to the
> product. I understand these do not exist just yet, is that correct? Is
> there an ETA?
>
> On Thu, Aug 6, 2015 at 8:45 AM Mircea Trofin <[email protected]> wrote:
>
>> I'm investigating.
>>
>> On Thu, Aug 6, 2015 at 8:43 AM Jaroslav Sevcik <[email protected]> wrote:
>>
>>> Ouch, the numbers do not look too good. Any idea what is going on in Lua
>>> binary trees and towers.c? Is it compilation time that suffers or is the
>>> code quality worse?
>>>
>>> On Thu, Aug 6, 2015 at 5:36 PM, Mircea Trofin <[email protected]>
>>> wrote:
>>>
>>>> I though I sent perf earlier:
>>>>
>>>>
>>>> https://docs.google.com/spreadsheets/d/1x_W2r5DxIj8dySqMBgZw9zrodaOcjvh8XGuK-vhCBso/edit#gid=1835643316
>>>>
>>>> see the "Deferred Blocks - do not split spill operands" tab.
>>>>
>>>>
>>>> On Thu, Aug 6, 2015 at 5:28 AM <[email protected]> wrote:
>>>>
>>>>> I think I understand now how the spilling works, but it is very subtle.
>>>>> Once you
>>>>> add explanatory comments, it will be good to go.
>>>>>
>>>>> What are the performance numbers?
>>>>>
>>>>>
>>>>>
>>>>> https://codereview.chromium.org/1271703002/diff/80001/src/compiler/register-allocator.cc
>>>>> File src/compiler/register-allocator.cc (right):
>>>>>
>>>>>
>>>>> https://codereview.chromium.org/1271703002/diff/80001/src/compiler/register-allocator.cc#newcode408
>>>>> src/compiler/register-allocator.cc:408
>>>>> <https://codereview.chromium.org/1271703002/diff/80001/src/compiler/register-allocator.cc#newcode408src/compiler/register-allocator.cc:408>:
>>>>> // the range and control flow
>>>>> connection mechanism instead.
>>>>> Please elaborate on how this uses the control flow connection
>>>>> mechanism.
>>>>>
>>>>> This incremental build-up of various moves is in my opinion the worst
>>>>> part of the register allocator (in terms of understandability and
>>>>> maintainability), and this CL makes it worse. It should be explained in
>>>>> the comments.
>>>>>
>>>>>
>>>>> https://codereview.chromium.org/1271703002/diff/80001/src/compiler/register-allocator.h
>>>>> File src/compiler/register-allocator.h (right):
>>>>>
>>>>>
>>>>> https://codereview.chromium.org/1271703002/diff/80001/src/compiler/register-allocator.h#newcode417
>>>>> src/compiler/register-allocator.h:417
>>>>> <https://codereview.chromium.org/1271703002/diff/80001/src/compiler/register-allocator.h#newcode417src/compiler/register-allocator.h:417>:
>>>>> // in which it may be worse to
>>>>> spill in it.
>>>>> The comment seems to be out of date (it refers to the ranges with just
>>>>> one spilled child).
>>>>>
>>>>> https://codereview.chromium.org/1271703002/
>>>>>
>>>>
>>>
>>>
>>> --
>>> ----------------------------------------------
>>>
>>>
>>>
>>> *Jaroslav SevcikSoftware EngineerGoogle Germany GmbH*
>>> *Dienerstr. 12*
>>>
>>> *80331 München*
>>> ----------------------------------------------
>>> Geschäftsführer: Graham Law, Christine Elizabeth Flores
>>>
>>> Sitz der Gesellschaft: Hamburg
>>>
>>> Registergericht und -nummer: Hamburg, HRB 86891
>>>
>>>
>>> Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind,
>>> leiten Sie diese bitte nicht weiter, informieren Sie den Absender und
>>> löschen Sie die E-Mail und alle Anhänge. Vielen Dank.
>>>
>>>
>>>
>>> This e-mail is confidential. If you are not the right addressee please
>>> do not forward it, please inform the sender, and please erase this e-mail
>>> including any attachments. Thanks.
>>>
>>> Der Inhalt dieser E-Mail spiegelt den derzeitigen Stand der
>>> Verhandlungen wider und dient als Basis für weitere Gespräche. Er soll
>>> keine rechtlich verbindliche Verpflichtung begründen. Eine solche
>>> Verpflichtung wird allein durch einen zwischen allen beteiligten Parteien
>>> abgeschlossenen, schriftlichen Vertrag geschaffen.
>>>
>>> The above terms reflect a potential business arrangement, are provided
>>> solely as a basis for further discussion, and are not intended to be and do
>>> not constitute a legally binding obligation. No legally binding obligations
>>> will be created, implied, or inferred until an agreement in final form is
>>> executed in writing by all parties involved.
>>>
>>>


-- 
----------------------------------------------



*Jaroslav SevcikSoftware EngineerGoogle Germany GmbH*
*Dienerstr. 12*

*80331 München*
----------------------------------------------
Geschäftsführer: Graham Law, Christine Elizabeth Flores

Sitz der Gesellschaft: Hamburg

Registergericht und -nummer: Hamburg, HRB 86891


Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind,
leiten Sie diese bitte nicht weiter, informieren Sie den Absender und
löschen Sie die E-Mail und alle Anhänge. Vielen Dank.



This e-mail is confidential. If you are not the right addressee please do
not forward it, please inform the sender, and please erase this e-mail
including any attachments. Thanks.

Der Inhalt dieser E-Mail spiegelt den derzeitigen Stand der Verhandlungen
wider und dient als Basis für weitere Gespräche. Er soll keine rechtlich
verbindliche Verpflichtung begründen. Eine solche Verpflichtung wird allein
durch einen zwischen allen beteiligten Parteien abgeschlossenen,
schriftlichen Vertrag geschaffen.

The above terms reflect a potential business arrangement, are provided
solely as a basis for further discussion, and are not intended to be and do
not constitute a legally binding obligation. No legally binding obligations
will be created, implied, or inferred until an agreement in final form is
executed in writing by all parties involved.

-- 
-- 
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
--- 
You received this message because you are subscribed to the Google Groups 
"v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to