[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