[llvm-commits] [llvm-gcc-4.0] r42134 - /llvm-gcc-4.0/trunk/gcc/llvm-convert.cpp

[Chris Lattner]

On Sep 19, 2007, at 7:51 AM, Dale Johannesen wrote:
> On Sep 19, 2007, at 7:46 AM, Duncan Sands wrote:
>>> Code downstream, starting with EmitBuiltinUnaryFPOp, is not ready  
>>> for
>>> long double functions.  This is not the best or a permanent fix, but
>>> correct for the moment.
>>
>> I see - thanks.  By the way, how do you plan to handle constant
>> folding of sqrt and friends when the host doesn't handle long  
>> doubles?
>
> It can be done by emulation in APFloat, but it's not a high priority
> for me (I'm not a numerics expert, but this is the sort of thing you
> can look up).  In  the short term that just won't be done.

To elaborate a bit more: one of the nice features of APFloat is that  
we never do FP constant folding with host arithmetic operations  
(everything is done with 'softfloat').  This ensures we get  
deterministic results, as powerpc long double and x86 long double are  
very different.  We also do this for float and double since they have  
similar problems (just not on any architectures we support now) so we  
might as well handle them for uniformity and to make sure the code is  
well tested.

One problem Dale:

@@ -4350,9 +4351,10 @@
+  case BUILT_IN_POWIL:
+    return false;   // treat long double as normal call
    case BUILT_IN_POWI:
    case BUILT_IN_POWIF:
-  case BUILT_IN_POWIL:
      Result = EmitBuiltinPOWI(exp);
      return true;

I don't think this works.  There is no "powil" function for llvm-gcc  
to fall back on.  Not handling this builtin will result in a call to  
__builtin_powil, which will fail at link-time.  I had to handle these  
explicitly here because "fold" produces these operations in some  
cases.  Try long double X*X*X with -ffast-math.

-Chris