[LLVMbugs] [Bug 6679] New: [x86] FUCOMIP and related instructions generated even on -mcpu=pentium

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Mon Mar 22 18:06:07 PDT 2010


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

           Summary: [x86] FUCOMIP and related instructions generated even
                    on -mcpu=pentium
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: craig at ni.com
                CC: clattner at apple.com, llvmbugs at cs.uiuc.edu,
                    craig at ni.com, d.g.gorbachev at gmail.com
        Depends on: 4841


+++ This bug was initially created as a clone of Bug #4841 +++

The FCOMI/FCOMIP/ FUCOMI/FUCOMIP instructions were added to the
Pentium Pro at the same time as conditional moves.  
While the -mattr=-cmov flag can disable conditional moves, there is still no
way to disable the floating point comparisons FCOMI, etc. which set EFLAGS

Processors older than Pentium Pro only have floating point comparisons such as
FCOM, FCOMP, etc., which set the x87 floating point status word with the result
rather than EFLAGS.
To set condition codes in order to branch on the result, you need to do
something like

  FUCOMP %st(1)
  FNSTSW   ; store x87 FP status word to AX
  SAHF        ; copy AH to EFLAGS
  JE ...

As it stands, using -cmov is not sufficient to generate code which will run on
pentium and earlier CPUs.

Also note that the definition of the older instructions in X86InstrFPStack.td 
(def UCOM_Fr, UCOM_FPr, and UCOM_FPPr have "let Defs = [EFLAGS]", which is not
correct.
(I'm not sure if it is actually possible to get LLVM to generate these
instructions currently.)

I had attached a proposed fix to this problem to Bug #4841 as part of the -cmov
switch, which used a pseudo-instruction to match X86cmp and generate the
pattern above, 
but Chris suggested I clone the bug and implement a fix during Legalize instead
of scheduling.

Unfortunately I'm a newbie at this, and this seems a bit harder.
Chris, to clarify your intent:

I would need to create X86 DAG Nodes for FUCOM, FNSTSW, and SAHF and generate
them in LowerSelectCC and other places in X86ISelLowering instead of
X86ISD::CMP whenever the feature test fails, and modify X86InstrFPStack to add
pattens to match them with the associated instructions.

Do I have this right?  Also, the FPSW does not seem to be modeled as a
pseudo-register, so will I have to do this in order to be able to model the
dependency between the FUCOM and FNSTSW SDNodes?

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