search for: f128

Hello, I'm new to this mailing list and fixing llvm bugs for Android. Can anyone point me to any previous discussion or work related to the following bug? https://llvm.org/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...

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 Akira > 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: It depends... There is some generic code here and there which can handle f128, but some parts are still missed. You might need to fill them... -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mec...

...the TargetDescription string documentation is. I am reading the tutorial and looking at the sparc backend at the same time and there are some discrepancies. Therefore the documentation would be extremely valuable but I can't seem to find it. In the tutorial it shows the string "E-p:32:32-f128:128:128", but the real sparc backend has "E-p:32:32:32-i16:16:16-f32:32:32-f128:64:64-n32". The tutorial doesn't explain what the 'n' stands for, or why 'f' shows up twice (I can guess the first might be for floats and the second for doubles, but the tutorial has...

In "Writing an LLVM Compiler Backend", there's some discussion of the TargetDescription string, but it doesn't explain the examples I look at. For instance, in the description of the PowerPC, I see "E-p:64:64-f64:64:64-i64:64:64-f128:64:128-n32:64" What's "preferred alignment" versus "ABI alignment"? What are the 3 figures following the "i"? (the documentation suggests there will only be 2). I see two entries for "f". Do I read these as info about "f64" and "f1...

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

...er.  If I just go this path, then I am setting sret on an integer pointer, which verify objects too.  LangRef doesn't say scalars are allowed to have sret set, but sret is used for vectors. So my question is: should I, when updating the llvm-gcc, not set sret on my i128 shadow returns (also on f128), or should Verify accept sret on scalar pointers, not just struct or vector pointers? Andrew

...18, at 14:00, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I haven't dug into the GlobalISel calling convention code much but I can comment on the MipsCCState. Thanks for the insight Daniel, much appreciated. >> * MipsCCState: adds bool vectors OriginalArgWasF128, OriginalArgWasFloat, >> OriginalArgWasFloatVector, OriginalRetWasFloatVector, CallOperandIsFixed. Also >> a SpeciallCallingConv field. Provides its own implementation of >> AnalyzeFormalArguments etc that fill these vectors. > > CallOperandIsFixed was needed because the CCI...

...bury via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> I haven't dug into the GlobalISel calling convention code much but I can comment on the MipsCCState. > > Thanks for the insight Daniel, much appreciated. > >>> * MipsCCState: adds bool vectors OriginalArgWasF128, OriginalArgWasFloat, >>> OriginalArgWasFloatVector, OriginalRetWasFloatVector, CallOperandIsFixed. Also >>> a SpeciallCallingConv field. Provides its own implementation of >>> AnalyzeFormalArguments etc that fill these vectors. >> >> CallOperandIsFixed was n...

I need to return i128 and f128 via a ptr passed in as the first argument to a function. I am not seeing something in llvm-abi.h to let me do this. How do I make a scalar (not an aggregate) use a shadow return? Similarly I need to pass those types by pointer, (byval arguments?) and don't see an obvious way to do that. Tha...

...tring documentation is. > I am reading the tutorial and looking at the sparc backend at the same > time and there are some discrepancies. Therefore the documentation > would be extremely valuable but I can't seem to find it. > > In the tutorial it shows the string "E-p:32:32-f128:128:128", > but the real sparc backend has > "E-p:32:32:32-i16:16:16-f32:32:32-f128:64:64-n32". > > The tutorial doesn't explain what the 'n' stands for, or why 'f' shows > up twice (I can guess the first might be for floats and the second for >...

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

...nted 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. It's a documentation bug; f128 refers to the LLVM type fp128 on SPARC. -Eli

...hen I am setting > sret on an integer pointer, which verify objects too. LangRef doesn't > say scalars are allowed to have sret set, but sret is used for > vectors. > > So my question is: should I, when updating the llvm-gcc, not set sret > on my i128 shadow returns (also on f128), or should Verify accept sret > on scalar pointers, not just struct or vector pointers? Hey Andrew, sret doesn't make sense on scalars or vectors. Where are you seeing it work with vectors? -Chris

...ca, then each element is stored to in turn. It would be nice if this array was transformed into a global constant array. Thanks, Nick ; ModuleID = 'WinterModule' target datalayout = "e-p:64:64:64-S128-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f16:16:16-f32:32:32-f64:64:64-f128:128:128-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" ; Function Attrs: nounwind readnone define i32 @"main(int)"(i32 %i, i32* nocapture %hidden) #0 { entry: %"Array literal space" = alloca [5 x i32], align 4 %0 = getelementptr [5 x i32]* %"Ar...

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:

The example code: ; ModuleID = 'struct_2.bc' target datalayout = "E-p:32:32:128-f64:64:128-f32:32:128-i64:32:128-i32:32:128-i16:16:128-i8:8:128-i1:8:128-a0:0:128-v128:128:128-s0:128:128" target triple = "spu" @boolvar = internal global i1 false define void @set_boolvar() nounwind { entry: store i1 true, i1* @boolvar, align 16 ret void } This gets

...+ F83 + F84 + F85 + F86 + F87 + F88 + F89 + F90 + F91 + F92 + F93 + F94 + F95 + F96 + F97 + F98 + F99 + F100 + F101 + F102 + F103 + F104 + F105 + F106 + F107 + F108 + F109 + F110 + F111 + F112 + F113 + F114 + F115 + F116 + F117 + F118 + F119 + F120 + F121 + F122 + F123 + F124 + F125 + F126 + F127 + F128 + F129 + F130 + F131 + F132 + F133 + F134 + F135 + F136 + F137 + F138 + F139 + F140 + F141 + F142 + F143 + F144 + F145 + F146 + F147 + F148 + F149 + F150 + , data = nose126s2) # weights: 512 (381 variable) > nose126s2.mu Call: multinom(formula = Spoilage ~ F25 + F26 + F27 + F28 + F29 + F30 +...

...isFloatingPoint filter? Looks like a bug to me. v2f32 = 22, // 2 x f32 v4f32 = 23, // 4 x f32 <== start ?? v2f64 = 24, // 2 x f64 <== end static inline bool isFloatingPoint(ValueType VT) { return (VT >= f32 && VT <= f128) || (VT >= v4f32 && VT <= v2f64); } 2. My problem seems to stem from what appears to be under-constrained typing of patterns. With vectors there is a challenge because currently there is no type constraint available to indicate that an operand can/cannot be a vector type, or...

The following piece of IR is a fixed point for opt -std-compile-opts/-O3: --- target datalayout = "e-p:64:64:64-S128-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f16:16:16-f32:32:32-f64:64:64-f128:128:128-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" target triple = "x86_64-unknown-linux-gnu" ; Function Attrs: nounwind readonly define i32 @get32Bits(i8* inreg nocapture readonly %x_arg) #0 { %tmp1 = getelementptr inbounds i8* %x_arg, i64 3 %tmp2 = load i...