[llvm-bugs] [Bug 34903] New: X86CallFrameOptimization wrongly assumes '= COPY %esp' is right after ADJCALLSTACKDOWN

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Oct 10 06:33:50 PDT 2017


https://bugs.llvm.org/show_bug.cgi?id=34903

            Bug ID: 34903
           Summary: X86CallFrameOptimization wrongly assumes '= COPY %esp'
                    is right after ADJCALLSTACKDOWN
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: zvi.rackover at intel.com
                CC: llvm-bugs at lists.llvm.org

SelectionDAG inserts a copy of ESP into a virtual register.
X86CallFrameOptimization assumes that the COPY, if present, is always
right after the call-frame setup instruction (ADJCALLSTACKDOWN). This is a
wrong assumption as the COPY can be located anywhere between the call-frame
setup instruction and its first use. If the COPY happened to be located in a
different location than what X86CallFrameOptimization assumed, visiting it
while processing the call chain would lead to a conservative bail-out.

Here's an example of .mir captured from movtopush.ll, function 'test9'. You can
see that the instruction '%3 = copy %esp' is *not* located immediately after
the adjcallstackdown32 instruction:

     callstackdown32 16, 0, 0, implicit-def dead %esp, implicit-def dead
%eflags, implicit %esp
     %0 = copy %esp
     mov32mi %0, 1, _, 12, _, 4 :: (store 4 into stack + 12)
     mov32mi %0, 1, _, 8, _, 3 :: (store 4 into stack + 8)
     mov32mi %0, 1, _, 4, _, 2 :: (store 4 into stack + 4)
     mov32mi %0, 1, _, 0, _, 1 :: (store 4 into stack)
     callpcrel32 @good, csr_32, implicit %esp, implicit-def %esp
     adjcallstackup32 16, 0, implicit-def dead %esp, implicit-def dead %eflags,
implicit %esp
     adjcallstackdown32 20, 0, 0, implicit-def dead %esp, implicit-def dead
%eflags, implicit %esp
     %1 = mov32rm %stack.2.s, 1, _, 0, _ :: (load 4 from %stack.2.s, align 8)
     %2 = mov32rm %stack.2.s, 1, _, 4, _ :: (load 4 from %stack.2.s + 4)
     %3 = copy %esp
     mov32mr %3, 1, _, 4, _, killed %2 :: (store 4)
     mov32mr %3, 1, _, 0, _, killed %1 :: (store 4)
     %4 = lea32r %stack.0.p, 1, _, 0, _
     mov32mr %3, 1, _, 16, _, killed %4 :: (store 4 into stack + 16)
     %5 = lea32r %stack.1.q, 1, _, 0, _
     mov32mr %3, 1, _, 12, _, killed %5 :: (store 4 into stack + 12)
     mov32mi %3, 1, _, 8, _, 6 :: (store 4 into stack + 8)
     callpcrel32 @struct, csr_32, implicit %esp, implicit-def %esp
     adjcallstackup32 20, 0, implicit-def dead %esp, implicit-def dead %eflags,
implicit %esp
     ret 0

-- 
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/20171010/1fb5d92a/attachment.html>


More information about the llvm-bugs mailing list