Hi Tim,<br><br><div class="gmail_quote">On Tue, Jan 8, 2013 at 5:07 AM, Tim Northover <span dir="ltr"><<a href="mailto:Tim.Northover@arm.com" target="_blank">Tim.Northover@arm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Renato,<br>
<br>
Thanks for your comments on this too.<br>
<div><br>
On Tuesday 08 Jan 2013 11:22:01 Renato Golin wrote:<br>
> +  return TLI.makeLibCall(DAG, GetFPLibCall(N->getValueType(0),<br>
> +                                           RTLIB::ADD_F32,<br>
> +                                           RTLIB::ADD_F64,<br>
> +                                           RTLIB::ADD_F80,<br>
> +                                           RTLIB::ADD_PPCF128),<br>
> +                         NVT, Ops, 2, false, N->getDebugLoc());<br>
><br>
> Shouldn't this (and all other variations) also take into account the IEEE<br>
> variation of long doubles?<br>
<br>
</div>It was an active decision not to. AArch64 will not make any use of this code<br>
so it would be truly untestable as far as I'm aware.<br>
<div><br></div></blockquote><div><br>Doesn't aarch64 use library functions for soft-float (llc -soft-float)?<br><br>mips64/linux also treats long double as 128-bit quad
 precision type. mips64-gcc calls the same software emulation library function 
("__addtf3" for add) in soft-float mode (arguments are passed in integer
 registers), so probably mips64 will need to pass RTLIB::ADD_F128 here.<br>


<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
> As far as I can tell (I'm not a diff engine), the main move was<br>
> softenSetCCOperands() and makeLibCall() going to TargetLowering. Your<br>
> description doesn't tell why this is necessary at all and it's hard to<br>
> point it out from the diff, since they're in different files and<br>
> everything appears different, but look similar enough.<br>
<br>
</div>It's necessary so that the AArch64 backend can call these functions from<br>
ISelLowering to handle its IEEE quads.<br>
<div><br>
> If the move was just good, not necessary, it'd be easier to have it in two<br>
> changes: one with the real change (with a small diff) and another with the<br>
> code move (for the sake of simplicity and code organization).<br>
<br>
</div>I think that move is the entirity of the change, there is nothing else to<br>
split off that I can see.<br>
<br>
Cheers.<br>
<br>
Tim.<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</blockquote></div><br>