[llvm-bugs] [Bug 32544] New: [X86] Unnecessary GR32->GR32 created to zero upper 32-bits or GR64 for zext of basic block input

[via llvm-bugs]

http://bugs.llvm.org/show_bug.cgi?id=32544

            Bug ID: 32544
           Summary: [X86] Unnecessary GR32->GR32 created to zero upper
                    32-bits or GR64 for zext of basic block input
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: craig.topper at gmail.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 18233
  --> http://bugs.llvm.org/attachment.cgi?id=18233&action=edit
Test case

Because we do isel one basic block at a time, if a basic block contains a zext
i32->i64 of a value produced in another basic block we lose the ability to
determine if the earlier instruction zeroed the upper bits. So we emit an extra
MOV32rr to zero out the bits.

This looks particularly bad when we use the same register for the src and dst
of the move.

The attached test case contains two functions that differ in the placement of
the zext. The one with the zext only in the final block generates an extra
move.

If you run the test through InstCombine you'll also see that even if the zext
starts in the earlier blocks it will get moved to the final block.

Should we teach InstCombine or CodeGenPrepare to hoist "free" zexts closer to
their defs instead of sinking them.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170405/f5e9e239/attachment.html>