[Webkit-unassigned] [Bug 151315] New: If B3->Air lowering moves a child to the result tmp when using an Inst with a x86-style UseDef operand, then other uses of that child should also use the result tmp

[bugzilla-daemon at webkit.org]

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

            Bug ID: 151315
           Summary: If B3->Air lowering moves a child to the result tmp
                    when using an Inst with a x86-style UseDef operand,
                    then other uses of that child should also use the
                    result tmp
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: fpizlo at apple.com

Consider this:

Int32 @2 = Add(@1, @1)

Ignoring for a moment the fact that this goes through Shl as a result of reduceStrength(), we will currently do this:

tmp mapping:
@1 -> %tmp1
@2 -> %tmp2

Move %tmp1, %tmp2
Add32 %tmp1, %tmp2

This prevents us from coalescing %tmp1 and %tmp2, since their live ranges overlap.  The solution is that when we decide to emit the result move, we also force a temporary substitution of s/%tmp1/%tmp2/g on the subsequent Inst.  This would cause us to do:

Move %tmp1, %tmp2
Add32 %tmp2, %tmp2

I believe that such a substitution is both correct and optimal. It's correct because we use arguments before we def them, so although the Add32 def's %tmp2, this happens after all arguments are consumed. Hence, %tmp2 is a correct substitute for %tmp1. It's also optimal, since it avoids the overlapping live range.

We have to be somewhat careful about how we implement this. Probably, the temporary substitution will be something that only some lowering rules opt into.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151116/7f60a463/attachment-0001.html>