[LLVMbugs] [Bug 3203] New: fast and burr schedulers break with complex EFLAGS usage

[bugzilla-daemon at cs.uiuc.edu]

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

           Summary: fast and burr schedulers break with complex EFLAGS usage
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sharparrow1 at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=2301)
 --> (http://llvm.org/bugs/attachment.cgi?id=2301)
Testcase (code patch)

Testcase is patch + IL.  Patch is attached; IL is as follows:

; ModuleID = '/tmp/x.bc'
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i386-pc-linux-gnu"

define i32 @a(i64 %a, i64 %b) nounwind readnone {
entry:
        %0 = icmp ult i64 %a, %b                ; <i1> [#uses=1]
        %1 = zext i1 %0 to i32          ; <i32> [#uses=1]
        ret i32 %1
}

The issue is that llc compiling this testcase on x86 crashes in scheduling
unless either "-pre-RA-sched=list-tdrr" or "-pre-RA-sched=list-td" is passed on
the llc commandline.  It's possible that this is my fault, but the fact that
some schedulers work points to a flaw in the other schedulers rather than my
patch.

For some background, the patch is a hacky work-in-progress for generating
significantly shorter code for comparisons between 64-bit integers on x86; the
patch isn't complete, and some parts are still messy, but I think the concept
is fundamentally sound.  Roughly, the idea is that a comparison on x86 is just
a subtraction, so we can do an efficient 64-bit comparison by just splitting
the subtraction, and testing the flags on the top half; since the CF, OF and SF
flags only depend on the top half of the result anyway, they will be set
correctly.  There is an issue in that the ZF flag isn't set correctly for the
whole result, but this can be worked around: we simply don't use this method
for equality comparisons, and we swap the operands for other comparisons that
would normally require it.

I think that the scheduler is getting confused by the explicitly modeled SBB,
since it both uses and sets EFLAGS.

For reference, the code generated with one of the top-down schedulers:
a:
        movl    4(%esp), %eax
        movl    16(%esp), %ecx
        movl    8(%esp), %edx
        subl    12(%esp), %eax
        sbbl    %ecx, %edx
        setb    %al
        movzbl  %al, %eax
        ret

And the error generated with the default scheduler:
llc: /home/eli/llvm/lib/CodeGen/ScheduleDAG.cpp:370: void
llvm::ScheduleDAGTopologicalSort::AddPred(llvm::SUnit*, llvm::SUnit*):
Assertion `!HasLoop && "Inserted edge creates a loop!"' failed.

If more debug output would be helpful, please ask.


-- 
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.