[LLVMbugs] [Bug 18897] New: fucom pattern with undefined results

[bugzilla-daemon at llvm.org]

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

            Bug ID: 18897
           Summary: fucom pattern with undefined results
           Product: libraries
           Version: 3.3
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: jonas.maebe at elis.ugent.be
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 12087
  --> http://llvm.org/bugs/attachment.cgi?id=12087&action=edit
Reproducer test case

When compiling for an architecture that does not support fucomi and friends,
llc generates

fucom   %st(x)
<pop>   %st(x)
fnstsw  %ax

If %st(x) is at the top of the fpu stack, there is no problem because the fucom
is simply changed in fucomp. However, if it's not at the top of the fpu stack,
the the <pop> is changed into "fstp %st(x)" and fstp leaves the fpu status
flags in an undefined state according to the Intel manuals (and also according
to the information encoded in X86InstrFPStack.td).

To reproduce: compile the attached source code (extracted from SPEC2006
libquantum) with clang -march=i486 -O2 -S and search for "fucom" in the
generated code. It will look like this:

        faddp   %st(1)
        fxch    %st(3)
        fucom   %st(3)
        fstp    %st(3)
        fnstsw  %ax
                                        # kill: AX<def> AX<kill> EAX<def>
                                        # kill: AH<def> AH<kill> EAX<kill>
        sahf
        jbe     .LBB0_4

I'm using clang/llvm 3.4, but couldn't select this in the version field. I also
checked the source code of trunk, but did not see any changes to
lib/Target/X86/X86FloatingPoint.cpp that suggest this bug is already fixed.
Afaics, the problem is in FPS::handleCompareFP when it calls
freeStackSlotAfter, in case that one in turn has to call freeStackSlotBefore.

The attachment not a runnable test, and I'm not even sure whether the result
would actually fail because libquantum works fine when compiled with those
parameters even though it contains the invalid code. I only discovered the
problem after our own post-link time optimizer removed the "fucom" as dead code
because it determines that its result is not used (the values read by the
fnstsw, other than C1, are (un)defined by the fstp).

-- 
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/20140219/b0b3d7a4/attachment.html>