search for: fp6

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 the floati...

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 Graduate Student University of Maryl...

...as 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 machine. > Is there an as...

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

...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 controlled by the calling convention o...

...10, 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 really >> be controlled by the c...

...degger 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 really >>> be...

...cted - 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 controlled by the call...

...he 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 libc.so.6 0x00007f23f7fe...

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

...-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,dead>, %MM3<imp-def,dead>, %MM4<imp-def,dead>, %MM5<imp-def,dead>, %MM6<imp-def,dead>, %MM7<imp-def,dead>, %XMM0<imp-def,d...

...%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,dead>, %MM3<imp-def,dead>, > %MM4<imp-def,dead>, %MM5<imp-def,dead>, %MM6<imp-def,dead>, > %MM7<imp-def,dead>...

...,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>, %ST(0)<imp-def,dead>, %MM0<imp-def,dead>, %MM1<imp-def,dead>, %MM2<imp-def,dead>, %MM3<imp-def,dead>, %MM4<imp-def,dead>, %MM5<imp-def,dead>, %MM6<imp-def,dead>, %MM7<imp-def,dead>, %XMM0<imp-def,dead>, %XMM1<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>, %ST(0)<imp-def,dead>, %MM0<imp-def,dead>, > %MM1<imp-def,dead>, %MM2<imp-def,dead>, %MM3<imp-def,dead>, > %MM4<imp-def,dead>, %MM5<imp-def,dead>, %MM6<imp-def,dead>, > %MM7<imp-def,dead>, %XMM0<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>, %ST(0)<imp-def,dead>, %MM0<imp-def,dead>, > > %MM1<imp-def,dead>, %MM2<imp-def,dead>, %MM3<imp-def,dead>, > > %MM4<imp-def,dead>, %MM5<imp-def,dead>, %MM6<imp-def,dead>, > > %MM7<imp-def,dead>, %XMM0<imp...

...ef,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>, %ST(0)<imp-def,dead>, %MM0<imp-def,dead>, >>> %MM1<imp-def,dead>, %MM2<imp-def,dead>, %MM3<imp-def,dead>, >>> %MM4<imp-def,dead>, %MM5<imp-def,dead>, %MM6<imp-def,dead>, >>> %MM7<imp-def,dead>, %XM...