[Webkit-unassigned] [Bug 152365] New: B3->Air lowering incorrectly copy-propagates over ZExt32's

[bugzilla-daemon at webkit.org]

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

            Bug ID: 152365
           Summary: B3->Air lowering incorrectly copy-propagates over
                    ZExt32's
    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

Copy propagating over ZExt32's seemed pretty clever at the time, but this is not something that belongs in the lowering.  The problem is that it assumes that certain operations zero-extend for you.  But that's not the case if the operation spills.

Here are some possible solutions:

1) Just turn off copy propagation: This will work, but it will cause pointless zero-extension operations.

2) (1) + add copy propagation to Air: We could teach Air which operations do a 32-bit zero-extend as part of their Def if the destination is a register.  Like, we could add DefZExt32 and UseDefZExt32.  This means that the copy propagation would run after register allocation.

3) (2) + teach IRC to coalesce Move32's but without removing them.  Then instead of full-blown copy propagation, we can just have a forward analysis that proves which locations (registers, spill slots, etc) have a value that is already zero-extended.  The part of this that deals with spill slots could be flow-insensitive while the register part is flow-sensitive.

4) (3) + teach IRC that a Move32 is only coalescable if all of the values that flow into it are already zero-extended based on some forward flow analysis.  I think that this will work because coalescing only happens if both variables get a register, which means that the meaning of DefZExt32 and UseDefZExt32 is preserved.

5) Mandate that DefZExt32 and UseDefZExt32 don't admitsStack(), and keep the copy propagation in the lowering.  This means substantially less optimal code on x86.

Of these options, I think that I like (4) best, but I still need to convince myself that it's right.

-- 
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/20151216/5b0ecb3e/attachment.html>