compiler-rt's arm vfp o<= implementation

The implementation of an float ordered <= looks buggy, but maybe I’m not reading the assembly right. This is lesf2vfp.S in compiler-rt, and it has this code:


// extern int __lesf2vfp(float a, float b);
//
// Returns one iff a <= b and neither is NaN.
// Uses Darwin calling convention where single precision arguments are passsed 
// like 32-bit ints
//
DEFINE_COMPILERRT_FUNCTION(__lesf2vfp)
	fmsr	s14, r0     // move from GPR 0 to float register
	fmsr	s15, r1     // move from GPR 1 to float register
	fcmps	s14, s15
	fmstat
	movls	r0, #1      // set result register to 1 if equal
	movhi	r0, #0
	bx	lr

If I read this right, the high bits of r0 are always cleared (by the movhi) while the low bits are conditionally set to 1 (by the movls), but there’s nothing to clear the r0’s low bits in the false case. Is this a bug or have I misunderstood the assembly?

Nick

movhi means mov if unsigned Higher

movls means mov if unsigned Lower or Same

so depending on the comparison result r0 holds 1 or 0

Rodolph.

movhi means mov if unsigned Higher

movls means mov if unsigned Lower or Same

so depending on the comparison result r0 holds 1 or 0

Thanks. Now that I understand the assembly, I think there’s another problem. libgcc’s definition of lesf2 is actually “1-(a<=b)”. Source: http://www.google.com/codesearch/p?hl=en#ulemn8tW-hg/pub/gcc/releases/gcc-2.95.2/gcc-core-2.95.2.tar.gz%7CInAiOEw9K4g/gcc-2.95.2/gcc/libgcc1.c&q=libgcc1%20lesf2

Shih-wei wrote a patch which reverses the meaning of the predicate (attached) and this works for us. Is this okay to commit?

Nick

les2vfp.patch (341 Bytes)