[Webkit-unassigned] [Bug 125755] New: a + b overflow check shouldn't keep both a and b alive on the exit path if they wouldn't have otherwise both been live

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Dec 14 22:05:56 PST 2013


https://bugs.webkit.org/show_bug.cgi?id=125755

           Summary: a + b overflow check shouldn't keep both a and b alive
                    on the exit path if they wouldn't have otherwise both
                    been live
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: fpizlo at apple.com
                CC: sam at webkit.org, ggaren at apple.com, oliver at apple.com,
                    barraclough at apple.com, msaboff at apple.com,
                    mhahnenberg at apple.com, mark.lam at apple.com,
                    nrotem at apple.com
            Blocks: 112840


Consider that we have a program like:

    return a + b

Currently we'll emit code like:

    movl %ecx, %rax
    addl %edx, %rax
    jo slow

Note the movl.  That's there because the OSR exit slow path will want both a and b, and so the result of the addition must go into a different register than either of the inputs.

But we could fix that if the OSR exit path undid the addition:

    %result = @llvm.sadd.with.overflow(%a, %b)
    if (extract %result, 1)
        exit(%a, %result - %a)

In this case, we can do an addl that destroys %b.

I've written some code at the FTL lowering level that does this, and it does seem to remove a bunch of movl's from the code for V8v7/crypto's am3() function.  But it's not an overall speed-up.  I suspect it would be better to do this optimization in LLVM.  It's pretty weird to do this at the time of LLVM IR generation.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list