FP problems in different backends?

Hi,

Here is yet another bug/miscompilation I've found while testing my
register allocator.

The compilation of the attached BC file fails on multiple backends, namely:
ia64, mips, mipsel, alpha

The failures are different from backend to backend (wrong register
classes, wrong operand types, etc). Please, just try to compile using
the attached BC file. I guess, it is related to the FP support.

May be I'm testing in the wong way?
What I currently do is:
1) I compile the source file on my X86 machine, using the following options:
   llvm-gcc -O6 -c -emit-llvm -o obj/cf1.c.bc cf1.c

I get this disassembled ll file:
; ModuleID = 'cf1.c.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"
@fl = external global float ; <float*> [#uses=1]
@a = weak global i32 0 ; <i32*> [#uses=1]

define void @mai() nounwind {
entry:
        %tmp = load float* @fl, align 4 ; <float> [#uses=1]
        %tmp1 = fcmp une float %tmp, 0.000000e+00 ; <i1> [#uses=1]
        br i1 %tmp1, label %bb, label %UnifiedReturnBlock

bb: ; preds = %entry
        store i32 10, i32* @a, align 4
        ret void

UnifiedReturnBlock: ; preds = %entry
        ret void
}

2) I generate code from the BC file using these e.g. options:
   llc --regalloc=linearscan -f cf1.c.bc -march=ia64

Could it be that llvm-gcc produces a target specific BC file and takes
e.g. target specific FP implementation and representation into
account? If so, how can I produce a correct BC file for a given
target, e.g. mips and afterwards test it?

I also attach a very simple original C source file.

Can someone confirm these failures? Any ideas about what is wrong with
this input file?

-Roman

cf1.c.bc (524 Bytes)

cf1.c (104 Bytes)

The compilation of the attached BC file fails on multiple backends, namely:
ia64, mips, mipsel, alpha

Hmm, looks like real bugs. None of those backends are very widely
used, so it's not too surprising there are issues. ia64 and alpha
are experimental, so issues are expected. I'm not sure of the status
of the mips backend; it might be worth filing a bug for that.

May be I'm testing in the wong way?

Well, in general, the output of llvm-gcc isn't portable, but besides
platform-specific intrinsics, llc shouldn't abort. Your testing
methodology isn't off as long as you don't care whether the result
actually runs, and there isn't anything wrong with the input files as
far as I can tell.

-Eli