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. -- -- 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.
