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

[Eli Friedman]

On Wed, Nov 9, 2011 at 2:16 PM, Hatanaka, Akira <ahatanaka at mips.com> wrote:
> 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.

I was just referring to the missing space after the comma.  Sorry
about the confusion.

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

Well, the fact that it's in two f64 registers is really a property of
the calling convention, not a fundamental property of f128... unlike
f128, ppcf128 is actually a pair of f64's, so it isn't really the best
example to follow.  I'm not sure the calling convention handling code
can handle this properly at the moment, though... if nobody else has a
suggestion, it's okay as-is, I guess, but at least add a comment to
explain what is going on.

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

Okay.  In that case, tests would be nice. :)

-Eli