search for: __float128

...dded the code for 128bit floating-point operations and tested these operations in i686, x86_64, SPARCv8 and SPARCv9 machines. Generated codes by LLVM operated normally when using x86_64, SPARCv8 and SPARCv9 machines, but generated codes in a x86 machine produce wrong result. Because Clang supports __float128 type, I also tried to test using Clang 3.9 version. However, I could not get the correct result of 128bit floating-point operations using Clang. For example, C source code that included operations of 128bit floating-point is as follows: #include <stdio.h> #include <quadmath.h> int ma...

...rg/bugs/show_bug.cgi?id=23897 I am testing my patch to llvm to make f128 values stay in SSE registers instead of being split into two i64 values. I have tried to add a register class FR128 to hold f128 values for the x86_64 target. Preliminary tests seem to be working and compatible with gcc's __float128 long double type. I found that long double complex (with two f128 values) also have calling convention compatibility problem with gcc and can be fixed similarly. My current patch does change quite a few places in type legalizing pass and some other optimizations related to f128 or i128 values. A f...

...er alignment? In this case Align is 8 and OrigAlign is 16 because SVT.getTypeForMVT() is Type::VectorTyID (<2 x i64>) which has an ABI type of VECTOR_ALIGN. Hmm...why is the ABI alignment for VectorTyID 16? The ABI certainly doesn't guarantee it. It only guarantees it for __int128, __float128 and __m128. Lots of other types can map to <2 x i64>. Any opinions on this? -Dave

On Fri, Jun 10, 2011 at 10:29 AM, David A. Greene <greened at obbligato.org> wrote: > Duncan Sands <baldrick at free.fr> writes: > >>> Yep.  There are lots of corner cases that the frontend MUST handle >>> because LLVM does not have the necessary infrastructure. >> >> I think it's more like: because LLVM doesn't have the necessary

...8 and OrigAlign is > 16 > because SVT.getTypeForMVT() is Type::VectorTyID (<2 x i64>) which has an > ABI > type of VECTOR_ALIGN. > > Hmm...why is the ABI alignment for VectorTyID 16? The ABI certainly > doesn't > guarantee it. It only guarantees it for __int128, __float128 and __m128. > Lots of other types can map to <2 x i64>. > > Any opinions on this? > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.ui...

On 4/16/19 4:18 PM, Amara Emerson wrote: On Apr 16, 2019, at 1:47 PM, Kaylor, Andrew via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Thanks, Hal. I hear what you are saying about the accuracy. The problem, from my perspective, is trying to explain to users what they are going to get. The constant folding may be as accurate as the lib call would

...// ::= y # unsigned long long, __int64 // ::= n # __int128 // ::= o # unsigned __int128 // ::= f # float // ::= d # double // ::= e # long double, __float80 // ::= g # __float128 // ::= z # ellipsis // ::= Dd # IEEE 754r decimal floating point (64 bits) // ::= De # IEEE 754r decimal floating point (128 bits) // ::= Df # IEEE 754r decimal floating point (32 bits) // ::= Dh # IEEE 754r...