[llvm-commits] [PATCH][Review request] IEEE quad software emulation library call

[Hatanaka, Akira]

I am not sure if I understand your first comment. Is it the trailing whitespace or incorrect indentation?
When I open my patch in an editor, it looks like what you see in the following link:

http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/102510

I didn't find any tabs either.


As for your second comment, I was copying what gcc-mips64 was doing. 
When I compile this code with gcc-mips64,
 
typedef long double LD;
LD g0, g1, g2;

LD f0() {
  return g0 + g1;
}

I get this code:

        ld      $2,%got_disp(g0)($28)
        ld      $25,%call16(__addtf3)($28)
        ldc1    $f12,0($2)
        sd      $31,8($sp)
        ldc1    $f13,8($2)
        ld      $2,%got_disp(g1)($28)
        ldc1    $f14,0($2)
        .reloc  1f,R_MIPS_JALR,__addtf3
1:      jalr    $25
        ldc1    $f15,8($2)

So g0 is passed in (f12, f13) and g1 is passed in (f14, f15). These are all FP registers.
Is the choice of register types platform dependent?

llc emits the code I expect to see after applying this patch for add, sub, mul and div.
I haven't made the changes needed for type conversions or fp constant operations.

________________________________________
From: Eli Friedman [eli.friedman at gmail.com]
Sent: Wednesday, November 09, 2011 1:42 PM
To: Hatanaka, Akira
Cc: llvm-commits at cs.uiuc.edu
Subject: Re: [llvm-commits] [PATCH][Review request] IEEE quad software emulation library call

On Wed, Nov 9, 2011 at 1:19 PM, Hatanaka, Akira <ahatanaka at mips.com> wrote:
> This patch adds code needed for expanding basic IEEE quad operations (add,
> sub, etc.) into software emulation library calls.

-
RTLIB::FLOOR_F80,RTLIB::FLOOR_PPCF128),
+                                         RTLIB::FLOOR_F80,RTLIB::FLOOR_F128,
+                                         RTLIB::FLOOR_PPCF128),

Whitespace, here and a couple other places nearby.

+  // f128 type is really two f64's.
+  if (!isTypeLegal(MVT::f128)) {
+    NumRegistersForVT[MVT::f128] = 2*NumRegistersForVT[MVT::f64];
+    RegisterTypeForVT[MVT::f128] = MVT::f64;
+    TransformToType[MVT::f128] = MVT::f64;
+    ValueTypeActions.setTypeAction(MVT::f128, TypeExpandFloat);
+  }

This looks wrong; I'm pretty sure we should be softening these (to
i128), not splitting into two f64's.

What else, if anything, is actually needed to make an f128 add work?

-Eli