[LLVMbugs] [Bug 1944] New: Scheduler deficiency on CodeGen/X86/pr1505b.ll

bugzilla-daemon at cs.uiuc.edu bugzilla-daemon at cs.uiuc.edu
Thu Jan 24 20:11:59 PST 2008


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

           Summary: Scheduler deficiency on CodeGen/X86/pr1505b.ll
           Product: libraries
           Version: 2.2
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: code-quality
          Severity: enhancement
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org
                CC: llvmbugs at cs.uiuc.edu


Consider the output of llvm-as < pr1505b.ll | llc -mcpu=i486:

        call    L_tan$stub
        fstpl   24(%esp)
...
        call    L__ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc$stub
        fldl    24(%esp)
        fstps   36(%esp)
        flds    36(%esp)
        fstpl   4(%esp)


24(%esp) is a f80 vreg that is live across a call, so it is spilled.  It's only
use is a truncstore (fstps) to the stack, which is used to truncate it.  The
only use of this stack slot is the flds which is used to reextend it after the
truncation is done.   This is all a single MBB, so the scheduler should produce
this code instead:

        call    L_tan$stub
        fstps   36(%esp)
...
        call    L__ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc$stub
        flds    36(%esp)
        fstpl   4(%esp)

By issuing the store early and the load late, the register is not live across
the call.  This is a very simple store+load to a frame index pattern, the input
chain to the store is the entry node, and the load depends on the store.  I
don't see any reason the scheduler should be prevented from doing this today.

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the llvm-bugs mailing list