search for: fp128

Is the llvm backend (legalize, isel, etc.) currently capable of handling type f128? I am trying to emit a call to __subtf3 when I compile the following bitcode: define fp128 @f1(fp128 %a0, fp128 %a1) nounwind readnone { entry: %sub = fsub fp128 %a0, %a1 ret fp128 %sub } This is for the Mips backend.

Hi Tim, Thanks for the hint. I tried the following, (it's a C interface since that's what I need it for) where a and b are the top and bottom halves of the 128 bit value, LLVMValueRef TestConst(LLVMContextRef C, uint64_t a, uint64_t b) { Type *ty = Type::getFP128Ty(*unwrap(C)); ArrayRef<uint64_t> ar[2] = {a,b}; APInt ai(128,*ar); APFloat quad(APFloat::IEEEquad(), ai); return wrap(ConstantFP::get(ty,quad)); } but for 1.0e0 it returns zero store fp128 0xL00000000000000000000000000000000, fp128* %e, align 16 and for 1.23e0 returns this, whic...

On Feb 16, 2009, at 6:36 PMPST, Chris Lattner wrote: > > On Feb 16, 2009, at 6:12 PM, aparna kotha wrote: > >> I am new to llvm and am stuck up with a problem. >> I am trying to initialize a Value* of type fp128 having the value 0 >> >> I am using the following construct >> >> ConstantFP::get(APFloat(APInt(128,0,false))); >> >> This is returning a double instead of a float and I am confused. >> >> Thanks a lot for your help. > > FP128Ty is stubbed out,...

...llvm.fmuladd.v16f32(<16 x float> %a, <16 x float> %b, <16 x float> %c)" without "-mattr=+fma" or "-mattr=+fma4" results in 16 calls for the fmaf libm function instead of AVX muls and adds. 2. On AArch64 targets, ISD::FMA nodes are formed for operations on fp128, resulting in a call to a software fp128 FMA implementation rather than a software fp128 multiply and a software fp128 add. This does not seem to be the intended behavior given the comment above; however, I am not sure if this is actually better or worse, since neither set of operations is supporte...

I am new to llvm and am stuck up with a problem. I am trying to initialize a Value* of type fp128 having the value 0 I am using the following construct ConstantFP::get(APFloat(APInt(128,0,false))); This is returning a double instead of a float and I am confused. Thanks a lot for your help. -- -- Aparna -------------- next part -------------- An HTML attachment was scrubbed... URL: <...

I figured it out. I was using this implementation of __chkstk from compiler-rt: DEFINE_COMPILERRT_FUNCTION(___chkstk) push %rcx cmp $0x1000,%rax lea 16(%rsp),%rcx // rsp before calling this routine -> rcx jb 1f 2: sub $0x1000,%rcx test %rcx,(%rcx) sub $0x1000,%rax cmp $0x1000,%rax ja 2b 1:

On Feb 16, 2009, at 6:12 PM, aparna kotha wrote: > I am new to llvm and am stuck up with a problem. > I am trying to initialize a Value* of type fp128 having the value 0 > > I am using the following construct > > ConstantFP::get(APFloat(APInt(128,0,false))); > > This is returning a double instead of a float and I am confused. > > Thanks a lot for your help. FP128Ty is stubbed out, but completely untested and not supported...

Hi, Just wondering if it's possible to construct a 128 bit quad precision floating point constant without converting the value back to a string. Cheers Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190410/a527f240/attachment.html>

On 7 March 2017 at 17:58, Reid Kleckner <rnk at google.com> wrote: > Today, the vast majority of target in Clang coerce aggregates passed this > way into appropriate word-sized types. They all use their own custom > heuristics to compute the LLVM types used for the coercions. It's terrible, > but this is the current consensus. > > I would like to improve the situation

Hello, I'm part of the (sadly fairly small) community of PS2 hackers. The current cross-toolchain for the PS2 is based on GCC 3.2.3, an outdated and buggy compiler, which I have personally gotten tired of working with, so I would like to port Clang as a newer cross-compiler for the PS2. However, the PS2 has some notable quirks which make this a non-trivial task for the current compiler. It

On Thu, May 27, 2010 at 7:09 PM, John Criswell <criswell at uiuc.edu> wrote: > I believe what you want is documented here: > > http://llvm.org/docs/LangRef.html#datalayout > Just a note, since it might be a bug on the backend or documentation. It says on the documentation that size for f is either 32 or 64, however, sparc has 64 and 128. -- PMatos

...http://llvm.org/docs/LangRef.html#datalayout >> > > Just a note, since it might be a bug on the backend or documentation. > It says on the documentation that size for f is either 32 or 64, > however, sparc has 64 and 128. It's a documentation bug; f128 refers to the LLVM type fp128 on SPARC. -Eli

...ag > (HasSpecialDivRemLowering), and update the remainder result If you setOperationAction on SDIVREM and UDIVREM to Custom you can expand the rtlib call appropriately yourself. There's precedent for sincos on Darwin systems (both ARM and x86) and in AArch64 for basically every operation on fp128. Cheers. Tim.

...d generally we want to be reasonably sure 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...

...into multiple values, or insert a padding value. For example, for the target mips64-unknown-linux-gnu, a call like printf("asdf%Lf", 1.0L); gets lowered to the following: %call = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([5 x i8], [5 x i8]* @.str, i32 0, i32 0), i64 undef, fp128 0xL00000000000000003FFF000000000000) #2" I would to hear more suggestions whether it is safe or not. Seems like for mips Clang produces some weird IR, but e.g. x86 IR seems ok. Any folks from Clang/LLVM to bring more information about "varargs vs ABI vs LLVM vs Clang"? And whether...

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

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

Folks, I'm working on bug 16387: "clang doesn't produce ARM EABI-compliant modulo runtime function" http://llvm.org/bugs/show_bug.cgi?id=16387 And I need some pointers. I've changed ARMISelLowering::ARMTargetLowering::ARMTargetLowering() to associate __aeabi_idivmod variants to RTLIB::{U,S}DIVREM_* library calls, but now I need to teach the expansion that on AEABI case,

...r insert a padding value. For > example, for the target mips64-unknown-linux-gnu, a call like > printf("asdf%Lf", 1.0L); gets lowered to the following: > > %call = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([5 x i8], > [5 x i8]* @.str, i32 0, i32 0), i64 undef, fp128 > 0xL00000000000000003FFF000000000000) #2" > > > I would to hear more suggestions whether it is safe or not. Seems like > for mips Clang produces some weird IR, but e.g. x86 IR seems ok. > > Any folks from Clang/LLVM to bring more information about "varargs vs ABI &gt...

...[| make_vector_type (float_type ()) 4; > 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;...