search for: x86floatingpoint

...to be straight-up stdcall. _ftol2 is > the only weird one. (There is an _ftol routine with the same calling > convention as _ftol2, but AFAIK it's only for backward compatibility > with older MSVC runtimes.) I'm far from an MSVC expert, though. Thanks. > Are there any docs for X86FloatingPoint? X86FloatingPoint.cpp with comments is all you get. /jakob

...s a stack frame. It messes with the x87 control word internally, > but the original control word is restored before returning. Alright. We definitely don't want to model it as a general call, then. Normal calls clobber lots of registers. The options are: 1. Use a pseudo-instruction that X86FloatingPoint understands and turns into a call after arranging for the argument to be in ST0. You should emit: %ST0 = COPY %vreg13; RFP80:%vreg13 %EAX, %EDX = FTOL2 %ST0<kill> %vreg16 = COPY %EAX<kill> %vreg17 = COPY %EDX<kill> Then teach X86FloatingPoint that FTOL2 pops it...

On Thu, Jan 19, 2012 at 10:39 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > Alright.  We definitely don't want to model it as a general call, then.  Normal calls clobber lots of registers. > > The options are: > > 1. Use a pseudo-instruction that X86FloatingPoint understands and turns into a call after arranging for the argument to be in ST0. >   You should emit: > >   %ST0 = COPY %vreg13; RFP80:%vreg13 >   %EAX, %EDX = FTOL2 %ST0<kill> >   %vreg16 = COPY %EAX<kill> >   %vreg17 = COPY %EDX<kill> > >   Then teach X86...

On Fri, Jan 20, 2012 at 2:10 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > X86FloatingPoint.cpp with comments is all you get. Thanks for your help, Jakob. Attached is a first-pass attempt at a patch. I don't want to post to -commits yet because I have no idea if this is fully correct, but it seems to work in simple test cases. Am I on the right track? Could this patch ever break in c...

...lvm/src/llvm/lib/Target/X86/X86CodeEmitter.cpp:437: warning: converting of negative value `-0x000000001' to `unsigned int' /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86CodeEmitter.cpp:437: warning: converting of negative value `-0x000000001' to `unsigned int' Compiling X86FloatingPoint.cpp /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86FloatingPoint.cpp: In member function `void<unnamed>::FPS::popStackAfter(llvm::ilist_iterator<llvm::MachineInstr>&)': /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86FloatingPoint.cpp:339: warning: converti...

On Jan 24, 2012, at 2:30 PM, Joe Groff wrote: > On Fri, Jan 20, 2012 at 2:10 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> X86FloatingPoint.cpp with comments is all you get. > > Thanks for your help, Jakob. Attached is a first-pass attempt at a > patch. I don't want to post to -commits yet because I have no idea if > this is fully correct, but it seems to work in simple test cases. Am I > on the right track? Yes, y...

...lvm/src/llvm/lib/Target/X86/X86CodeEmitter.cpp:437: warning: converting of negative value `-0x000000001' to `unsigned int' /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86CodeEmitter.cpp:437: warning: converting of negative value `-0x000000001' to `unsigned int' Compiling X86FloatingPoint.cpp /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86FloatingPoint.cpp: In member function `void<unnamed>::FPS::popStackAfter(llvm::ilist_iterator<llvm::MachineInstr>&)': /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86FloatingPoint.cpp:339: warning: converti...

...ive 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 Maryland, College Park -------------- next part -------------- An HTML att...

...get/X86/X86CodeEmitter.cpp:437: > warning: converting of negative value `-0x000000001' to `unsigned int' > /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86CodeEmitter.cpp:437: > warning: converting of negative value `-0x000000001' to `unsigned int' > Compiling X86FloatingPoint.cpp > /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86FloatingPoint.cpp: > In member function > `void<unnamed>::FPS::popStackAfter(llvm::ilist_iterator<llvm::MachineInstr>&)': > /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86FloatingPoint.cpp:339...

....edu> The buildbot build-self-4-mingw32 is failing with an assertion: Assertion failed: (isStackEmpty() && "Stack not empty at end of basic block?"), function processBasicBlock, file /Users/buildslave/zorg/buildbot/smooshlab/slave/build-self-4-mingw32/llvm.src/lib/Target/X86/X86FloatingPoint.cpp, line 305. Could anyone produce a bitcode file for that failure, please?---------- Forwarded message ---------- From: Jakob Stoklund Olesen <stoklund at 2pi.dk> Date: Sun, Jul 11, 2010 at 03:22 Subject: [LLVMdev] Bitcode from build-self-4-mingw32 To: LLVM Developers Mailing List <llvm...

...urrently trying to split intervals over loop boundaries. I have a situation where a floating point value is split over a loop boundary, and the register allocator choses to spill the value outside the loop. That leaves me with a floating point load in the loop preheader, which is crashing LLC with X86FloatingPoint.cpp:305: bool<unnamed>::FPS::processBasicBlock(llvm::MachineFunction&, llvm::MachineBasicBlock&): Assertion `isStackEmpty() && "Stack not empty at end of basic block?"' What's going on here? Where do floating point values which are live over BB boundaries li...

...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 assumption somewhere else, that I am missing. Yes, the default cpu on Linux is...

...your definition of the new instruction looks sane. > > However, you shouldn't expand the instruction right away in EmitInstrWithCustomInserter(), and leaving the pseudo and call instructions side by side is not going to work. > > Just leave the pseudo-instruction alone until it hits X86FloatingPoint, where you can rewrite it. > > Look at the code handling INLINE_ASM. You need to do the same, except you have fixed arguments STUses=1 and STClobbers=1, ST*=0. That should greatly simplify the code you need. That makes sense; thanks for the tip. Are the getCopyToReg(ST0) and addReg(ST0, Impl...

2012/1/19 Jakob Stoklund Olesen <stoklund at 2pi.dk>: > How many of these libcalls do you need to implement? What exactly is the calling convention? Which registers are clobbered etc. There is only one (that I know about so far). The MSVCRT `_ftol2` function implements floating-point-to-unsigned conversion for i386 targets, and LLVM 3.0 calls it with the cdecl calling convention for

On Jan 18, 2012, at 8:56 PM, Joe Groff wrote: > 2012/1/18 Jakob Stoklund Olesen <stoklund at 2pi.dk>: >> This should work: >> %1 = call i64 asm "call __ftol2", "=A,{st},~{dirflag},~{fpsr},~{flags},~{st}" (double %x) nounwind > > Forgive me for being slow, but what would be the best way to implement > the equivalent of that inline asm as a custom

...sy to choose either way. The whole thing is quite flexible; see LLVMTargetMachine::addCommonCodeGenPasses in lib/CodeGen/LLVMTargetMachine.cpp for a high-level overview of how CodeGen works. It might also be useful to look at LLVM handles x87 floating-point; the relevant code is in lib/Target/X86/X86FloatingPoint.cpp. > * When/where/how do things like big integer (iXXXXX), phi nodes, llvm.* > instrincs get lowered; e.g. does my target have to do that, or is it done > generically? Aribitrary-width integers, vectors, llvm.*, etc. are lowered generically by the Legalize infrastructure; the backend...

...ance Utility Version 8.00.40607 Copyright (C) Microsoft Corporation. All rights reserved. Build log was saved at "file://c:\dev\libs\llvm\win32\CodeGen\Debug\BuildLog.htm" CodeGen - 2 error(s), 0 warning(s) ------ Build started: Project: x86, Configuration: Debug Win32 ------ Compiling... X86FloatingPoint.cpp c:\Program Files\Microsoft Visual Studio 8\VC\include\xutility(196) : error C2784: 'bool std::operator <(const std::basic_string<_Elem,_Traits,_Alloc> &,const _Elem *)' : could not deduce template argument for 'const std::basic_string<_Elem,_Traits,_Ax> &'...

...ail. Run it with: llc -mcpu=i386 -march=x86-64 -mattr=-sse2 and get assertion below. Changing cpu does not 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 0x0000000000f75...

...607 >Copyright (C) Microsoft Corporation. All rights reserved. >Build log was saved at >"file://c:\dev\libs\llvm\win32\CodeGen\Debug\BuildLog.htm" >CodeGen - 2 error(s), 0 warning(s) >------ Build started: Project: x86, Configuration: Debug Win32 ------ >Compiling... >X86FloatingPoint.cpp >c:\Program Files\Microsoft Visual Studio 8\VC\include\xutility(196) : >error C2784: 'bool std::operator <(const >std::basic_string<_Elem,_Traits,_Alloc> &,const _Elem *)' : could not >deduce template argument for 'const >std::basic_string<_Elem,_Trait...

On Nov 19, 2009, at 5:28 PM, Jon Harrop wrote: > > Are these barfs due to bugs in my generated code or is this parts of LLVM not > honoring tail calls? It was a bug in LLVM, with emitting tail calls at -O0. It's now fixed, as of r89444. Dan