Bug 125755 - FTL: 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
Summary: FTL: a + b overflow check shouldn't keep both a and b alive on the exit path ...
Status: RESOLVED DUPLICATE of bug 126545
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Filip Pizlo
URL:
Keywords:
Depends on:
Blocks: 112840
  Show dependency treegraph
 
Reported: 2013-12-14 22:04 PST by Filip Pizlo
Modified: 2014-01-10 20:26 PST (History)
8 users (show)

See Also:


Attachments
the patch (17.34 KB, patch)
2013-12-14 22:05 PST, Filip Pizlo
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Filip Pizlo 2013-12-14 22:04:04 PST
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.
Comment 1 Filip Pizlo 2013-12-14 22:05:36 PST
Created attachment 219271 [details]
the patch

I don't think this works yet.
Comment 2 Filip Pizlo 2014-01-10 20:26:43 PST

*** This bug has been marked as a duplicate of bug 126545 ***