search for: fp0

...um(f) Fr <- cumsum(rev(f)) D <- (y - f)/(f + 1)^0.5 D <- sum(D[2:(K - 1)]^2)/(K - 2 - df) if (D > 1.5) warning(paste("f(z) misfit = ", round(D, 1), ". Rerun with increased df", sep = "")) if (nulltype == 3) { fp0 = matrix(NA, 6, 4) colnames(fp0) = c("delta", "sigleft", "p0", "sigright") } else { fp0 = matrix(NA, 6, 3) colnames(fp0) = c("delta", "sigma", "p0") } rownames(fp0) = c("thest", &...

Right. But there are 8 registers on the floating point stack from ST0 to ST7 and I think llvm is only using ST0 to ST6 in some code fragments. Could this be because of the assumption that X86::FP registers run from X86::FP0 to X86:FP6 ? --Aparna On Wed, May 25, 2011 at 2:28 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On May 25, 2011, at 11:09 AM, aparna kotha wrote: > > > Hi Guys, > > > > I was working on some floating point intensive benchmarks and realize > that...

Hi Guys, I was working on some floating point intensive benchmarks and realize that the floating point register allocation in llvm assumes that there are only 7 floating point registers in X86, whereas the hardware has 8. Line number 00266 assert(Reg >= X86::FP0 && Reg <= X86::FP6 && "Expected FP register!"); of X86FloatingPoint.cpp. Is there any reason for only counting from 0 to 6, when there are actually 8 in hardware ? Is there an assumption somewhere else, that I am missing. Thanks and Regards Aparna Kotha Gradua...

...rovide maximum iteration. iter<- function (Fpi, Time, tolerance){ S = 22.4 Ts = 0.499 Ti = 0.25 K = 0.044 r<- 1.5 M = Ts- Ti Ks = 0.044 Fpt = K*Time + M*S*log(1+ Fpi/(M*S)) while((Fpt-Fpi) > tolerance) { Fpi = Fpt Fpt = K*Time + M*S*log(1+ Fpi/(M*S)) Fp0 = Fpt } return(Fpt) } x<- iter(Fpi = 0.224, Time = 0.2, tolerance = 0.000001) But I want do something like this ( conceptually) for( i in 2:itermax) { Fpt[i] = K*Time + M*S*log(1+ Fpi/(M*S)) if((Fpt[i]- Fpt[i-1])<= tolerance) break print(Fpt[i] } something like this. any kind of help...

On Fri, Apr 10, 2009 at 5:24 PM, Devang Patel <dpatel at apple.com> wrote: > ... because usually a module pass operates on entire module (e.g. > inliner) and it does not require information specific to a function. > If your pass need info collected by a function pass then why not > structure your pass as a function pass and run it for all function in > a module ? I very much

...> Hi Guys, > > I was working on some floating point intensive benchmarks and realize that the floating point register allocation in llvm assumes that there are only 7 floating point registers in X86, whereas the hardware has 8. > > Line number > 00266 assert(Reg >= X86::FP0 && Reg <= X86::FP6 && "Expected FP register!"); > > of X86FloatingPoint.cpp. > > Is there any reason for only counting from 0 to 6, when there are actually 8 in hardware ? It has to do with the weird tricks that are needed to generate code for a stack...

On May 25, 2011, at 12:08 PM, aparna kotha wrote: > Right. But there are 8 registers on the floating point stack from ST0 to ST7 and I think llvm is only using ST0 to ST6 in some code fragments. Could this be because of the assumption that X86::FP registers run from X86::FP0 to X86:FP6 ? Yes. My guess it that the code converting from FP to ST registers sometimes needs the extra stack slot. /jakob

...people who have targets that are not in the main LLVM tree. I just checked in a patch (contributed by Jason Eckhardt) that makes the following changes: 1. The 'Register' tablegen class now requires a register name to be specified as an argument for the register. If you had this: def FP0 : Register; before, change it to: def FP0 : Register<"FP0">; 2. The RegisterAliases tablegen class is now gone. Instead, alias lists are encoded directly into the Register class, through the use of the RegisterGroup class. In the X86 backend, we used to have: def AL : Reg...

...I >> expected - the callee now indeed saved/restored all the xmm regs I >> added, however the calling code did not change at all... > > Look in X86InstrControl.td. The call instructions are all prefixed > by: > > let Defs = [RAX, RCX, RDX, RSI, RDI, R8, R9, R10, R11, FP0, FP1, FP2, > FP3, FP4, FP5, FP6, ST0, ST1, MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, > XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7, XMM8, XMM9, XMM10, > XMM11, XMM12, XMM13, XMM14, XMM15, EFLAGS], > > This is the fixed list of call-clobbered registers. It should really > be con...

On Oct 20, 2010, at 7:46 AM, Roland Scheidegger wrote: > On 20.10.2010 05:00, Jakob Stoklund Olesen wrote: >> Look in X86InstrControl.td. The call instructions are all prefixed >> by: >> >> let Defs = [RAX, RCX, RDX, RSI, RDI, R8, R9, R10, R11, FP0, FP1, FP2, >> FP3, FP4, FP5, FP6, ST0, ST1, MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, >> XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7, XMM8, XMM9, XMM10, >> XMM11, XMM12, XMM13, XMM14, XMM15, EFLAGS], >> >> This is the fixed list of call-clobbered registers. It should...

...; On Oct 20, 2010, at 7:46 AM, Roland Scheidegger wrote: > >> On 20.10.2010 05:00, Jakob Stoklund Olesen wrote: >>> Look in X86InstrControl.td. The call instructions are all prefixed >>> by: >>> >>> let Defs = [RAX, RCX, RDX, RSI, RDI, R8, R9, R10, R11, FP0, FP1, FP2, >>> FP3, FP4, FP5, FP6, ST0, ST1, MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, >>> XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7, XMM8, XMM9, XMM10, >>> XMM11, XMM12, XMM13, XMM14, XMM15, EFLAGS], >>> >>> This is the fixed list of call-clobbered r...

...lt wasn't what I > expected - the callee now indeed saved/restored all the xmm regs I > added, however the calling code did not change at all... Look in X86InstrControl.td. The call instructions are all prefixed by: let Defs = [RAX, RCX, RDX, RSI, RDI, R8, R9, R10, R11, FP0, FP1, FP2, FP3, FP4, FP5, FP6, ST0, ST1, MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7, XMM8, XMM9, XMM10, XMM11, XMM12, XMM13, XMM14, XMM15, EFLAGS], This is the fixed list of call-clobbered registers. It should re...

...ine/Orc/Core.h:1212 #22 0x00000001062eaf98 in decltype(std::__1::forward<void (*&)(llvm::orc::JITDylib&, std::__1::unique_ptr<llvm::orc::MaterializationUnit, std::__1::default_delete<llvm::orc::MaterializationUnit> >)>(fp)(std::__1::forward<llvm::orc::JITDylib&>(fp0), std::__1::forward<std::__1::unique_ptr<llvm::orc::MaterializationUnit, std::__1::default_delete<llvm::orc::MaterializationUnit> > >(fp0))) std::__1::__invoke<void (*&)(llvm::orc::JITDylib&, std::__1::unique_ptr<llvm::orc::MaterializationUnit, std::__1::default_dele...

...t help. I am using llc from the latest svn repository. Any suggestions to work around this? I need to disable sse2 instructions for x86-64. Thanks, -Peng -----error message------ llc: X86FloatingPoint.cpp:332: unsigned int getFPReg(const llvm::MachineOperand &): Assertion `Reg >= X86::FP0 && Reg <= X86::FP6 && "Expected FP register!"' failed. 0 llc 0x0000000000f75942 llvm::sys::PrintStackTrace(_IO_FILE*) + 34 1 llc 0x0000000000f75ed8 2 libpthread.so.0 0x00007f23f8edef60 3 libc.so.6 0x00007f23f7fe9165 gsignal + 53 4...

...mplication, though. A register class is not just a set of registers - it also holds information about spill size and alignment. Value types are no longer interesting once the selection DAG has been destroyed. X86 has the weird examples as usual: Classes RFP32, RFP64, and RFP80 are identical (FP0-6) except for the spill size. The same goes for FR64 and VR128 (XMM0-15). The coalescer will join these classes as follows: RFP32 + RFP64 -> RFP64 FR64 + VR128 -> VR128 This seems perfectly reasonable - choose the larger spill size and avoid losing data. TableGen thinks these classes...

Thanks for giving it a look! On 19.10.2010 23:21, Jakob Stoklund Olesen wrote: > On Oct 19, 2010, at 11:40 AM, Roland Scheidegger wrote: > >> So I saw that the code is doing lots of register >> spilling/reloading. Now I understand that due to calling >> conventions, there's not really a way to avoid this - I tried using >> coldcc but apparently the backend

...t;>>>> (*&)(llvm::orc::JITDylib&, >>>>> std::__1::unique_ptr<llvm::orc::MaterializationUnit, >>>>> std::__1::default_delete<llvm::orc::MaterializationUnit> >>>>> >)>(fp)(std::__1::forward<llvm::orc::JITDylib&>(fp0), >>>>> std::__1::forward<std::__1::unique_ptr<llvm::orc::MaterializationUnit, >>>>> std::__1::default_delete<llvm::orc::MaterializationUnit> > >(fp0))) >>>>> std::__1::__invoke<void (*&)(llvm::orc::JITDylib&, >>>&gt...

...MM1<kill>, %XMM2<kill>, %XMM3<kill>, %AL<kill>, %RAX<imp-def>, %RCX<imp-def,dead>, %RDX<imp-def,dead>, %RSI<imp-def,dead>, %RDI<imp-def,dead>, %R8<imp-def,dead>, %R9<imp-def,dead>, %R10<imp-def,dead>, %R11<imp-def,dead>, %FP0<imp-def,dead>, %FP1<imp-def,dead>, %FP2<imp-def,dead>, %FP3<imp-def,dead>, %FP4<imp-def,dead>, %FP5<imp-def,dead>, %FP6<imp-def,dead>, %ST0<imp-def,dead>, %ST1<imp-def,dead>, %MM0<imp-def,dead>, %MM1<imp-def,dead>, %MM2<imp-def,de...

...#22 0x00000001062eaf98 in decltype(std::__1::forward<void > (*&)(llvm::orc::JITDylib&, > std::__1::unique_ptr<llvm::orc::MaterializationUnit, > std::__1::default_delete<llvm::orc::MaterializationUnit> > >)>(fp)(std::__1::forward<llvm::orc::JITDylib&>(fp0), > std::__1::forward<std::__1::unique_ptr<llvm::orc::MaterializationUnit, > std::__1::default_delete<llvm::orc::MaterializationUnit> > >(fp0))) > std::__1::__invoke<void (*&)(llvm::orc::JITDylib&, > std::__1::unique_ptr<llvm::orc::MaterializationUnit, &g...

...should live across the function call. My mistake, I though you had in mind what I call a “true” inter procedural registers allocator: one that changes the allocation at function boundaries as well. I.e., it may choose that it is more efficient to put the first argument of function foo is register FP0 even if the ABI says R0. With this kind of scheme, you break the ABI (and you need LTO to be allowed to do that), you need to “dynamically” adjust the calling convention to what the register allocator chooses, and moreover you need to be able to communicate to the other tools (dynamic linker, debug...