search for: ppc_fp128

...gt; endianness; although each individual double is. > Well I'm still trying to understand the code base, so I may get this completely wrong, but here is my understanding: Looking at the comment of TargetLowering::hasBigEndianPartOrdering, it seems that, all "internal types" (e.g. ppc_fp128, i128) are assumed to be little-endian, and for non-ppc_fp128 external values (raw register tuples or memory), the endianness follows the data layout endianness; for ppc_fp128 external values (a pair of float registers or memory chunk), it's always "big-endian" due to the policy. The...

...gt; > > > Well I'm still trying to understand the code base, so I may get this > > completely wrong, but here is my understanding: > > > > Looking at the comment of TargetLowering::hasBigEndianPartOrdering, > > it seems that, all "internal types" (e.g. ppc_fp128, i128) are assumed > > to be little-endian, and for non-ppc_fp128 external values (raw > > register tuples or memory), the endianness follows the data layout > > endianness; for ppc_fp128 external values (a pair of float registers > > or memory chunk), it's always "...

Hi, I'm recently trying to investigate ppc_fp128 related problem. Here is a minimal C++ test case that seems wrongly compiled: long double id(long double a) { return a; } bool f(long double x) { return id(__builtin_fabsl(x)) >= 0; } int main() { if (f(-123.l)) { return 0; } return 1; } The program compiled with command: clang++...

Hi All, I am looking at a linker error under O2: undefined symbol __lshrdi3 I have two questions here: 1. Does that mean our libgcc (?) doesn't implement __lshrdi3? Or more generally, why I have such linker error? 2. Seems some operations are combined, and replaced with __lshrdi3 call. I am interested in when such libcall will be generated? Could you show me one

On 1 December 2015 at 13:41, Tim Shen via llvm-dev <llvm-dev at lists.llvm.org> wrote: > As a simple solution, when see a LLVM IR bitcast, instead of generating > (ISD::BITCAST x), can we generate (exchange_hi_lo (ISD::BITCAST x)) instead? An LLVM bitcast is defined to be equivalent to a store/load pair. Changing that for ISD::BITCAST would be very surprising, and I wouldn't

I have found some internal test failures due to the wrong constant folding on ppc_fp128. As documented in APFloat::PPCDoubleDouble, APFloat doesn't support PowerPC double-double correctly < https://github.com/llvm-mirror/llvm/blob/492acdd450bcdf9837494d6da029ed064f14fc33/lib/Support/APFloat.cpp#L74 >. To support this, we need to add a second tuple of (sign, exponent, signi...

...r" <echristo at gmail.com> > > Sent: Friday, September 30, 2016 4:43:12 PM > > Subject: [PPC, APFloat] Add full PPCDoubleDouble to APFloat > > > > > > > > > > I have found some internal test failures due to the wrong constant > > folding on ppc_fp128. > > > > > > As documented in APFloat::PPCDoubleDouble, APFloat doesn't support > > PowerPC double-double correctly < > > > https://github.com/llvm-mirror/llvm/blob/492acdd450bcdf9837494d6da029ed064f14fc33/lib/Support/APFloat.cpp#L74 > > >. > >...

...make_pointer_type > (make_struct_type [| double_type (); > x86fp80_type (); > fp128_type (); > ppc_fp128_type () > |] true); > make_pointer_type > (make_struct_type [| make_integer_type 1; > make_integer_type 3; > i8_type (); >...

...; make_pointer_type (make_struct_type [| double_type (); x86fp80_type (); fp128_type (); ppc_fp128_type () |] true); make_pointer_type (make_struct_type [| make_integer_type 1; make_integer_type 3; i8_type ();...

Matt: that’s fair. We’re generally apprehensive of option 2 as well. Eli: Yes, currently we believe that aarch64.neon.addp is the only arm64 one affected, but we don’t know how prevalent this is on other targets. Splitting it is certainly possible combined with the autoupgrader. If disambiguating the intrinsics is the preferred solution, then I think we should also have the langref also specify

"Finkel, Hal J." <hfinkel at anl.gov> writes: > I think that it's really important that we're specific about the goals > here. Exactly what kinds of optimizations are we aiming to (more-easily) > enable? There certainly exists hardware with instructions that help > vectorize complex multiplication, for example, and having a builtin > complex type would

...ons for declaring half variables and arrays, dereferencing half pointers, performing arithmetic and conversions, etc. The latest version of the C++ ABI supports half as well. Therefore, we believe half should become a fundamental type in LLVM. (After all, LLVM already supports x86_fp80, fp128 and ppc_fp128.) Anton. -------------- next part -------------- A non-text attachment was scrubbed... Name: 00003-half-llvm.patch Type: application/octet-stream Size: 12007 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110223/d954665d/attachment.obj> --------------...

...ure that it'll be maintained. > BTW, in the doc I was reading there was not mention about Quad size numbers, > decimal numbers and extended precision numbers. > http://llvm.org/docs/LangRef.html#type-system There appear to be numerous mentions of fp128 (which is IEEE quad-precision), ppc_fp128 and x86_fp80 (at least one of which probably qualifies as extended precision). Of course, those types have much more limited support in the backends than standard float and double. AArch64 should support fp128, and obviously ppc and x86 for their specific formats. Tim.

Many thanks for getting back. This will come in handy if you do not have a floating point unit. Also for speed in some cases. To be generic as possible it might be good to have this. BTW, in the doc I was reading there was not mention about Quad size numbers, decimal numbers and extended precision numbers. http://llvm.org/docs/LangRef.html#type-system -------------- next part -------------- An

...lf variables and > arrays, dereferencing half pointers, performing arithmetic and conversions, > etc. The latest version of the C++ ABI supports half as well. Therefore, > we believe half should become a fundamental type in LLVM. (After all, LLVM > already supports x86_fp80, fp128 and ppc_fp128.) Hi Anton, Does the spec force evaluation to happen in half mode, or does it specify that there is a promotion to float (or some other type) an operation, then truncation back to half? -Chris

...nt complex numbers. c16 - Complex of 16-bit float c32 - like float complex or std::complex<float> c64 - like double complex or std::complex<double> x86_c80 - Complex of x86_fp80 c128 - like long double complex or std::complex<long double> ppc_c128 - Complex of ppc_fp128 Note that the references to C and C++ types above are simply explanatory. Nothing in this proposal assumes any particular high-level language type will map to the above LLVM types. The "underlying type" of a complex type is the type of its real and imaginary components. The sizes of t...

...nt complex numbers. c16 - Complex of 16-bit float c32 - like float complex or std::complex<float> c64 - like double complex or std::complex<double> x86_c80 - Complex of x86_fp80 c128 - like long double complex or std::complex<long double> ppc_c128 - Complex of ppc_fp128 Note that the references to C and C++ types above are simply explanatory. Nothing in this proposal assumes any particular high-level language type will map to the above LLVM types. The "underlying type" of a complex type is the type of its real and imaginary components. The sizes of th...

...- Complex of 16-bit float > c32 - like float complex or std::complex<float> > c64 - like double complex or std::complex<double> > x86_c80 - Complex of x86_fp80 > c128 - like long double complex or std::complex<long double> > ppc_c128 - Complex of ppc_fp128 > > Note that the references to C and C++ types above are simply explanatory. > Nothing in this proposal assumes any particular high-level language type will > map to the above LLVM types. > > The "underlying type" of a complex type is the type of its real and imagin...