search for: ftol2

...10:12 AM, Joe Groff wrote: > 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 > `fptoui to i64` when targeting i386-pc-win32. However, it has its own > calling convention: The input value is taken from ST0 and popped off &gt...

... 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 its argument, like FISTP64m. > > 2. Use inline asm. Which is pretty gross. You would need to construct a SelectionDAG node identical to the on...

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 `fptoui to i64` when targeting i386-pc-win32. However, it has its own calling convention: The input value is taken from ST0 and popped off of the x87 stack, and t...

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 lowering for an > instruction? Can I just create a CallInst and tell it to lower...

On Tue, Jan 24, 2012 at 4:32 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > Yes, 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

...check be easily modified so it doesn't store if the operand is already in memory and not actually in an SSE register? Should FP_TO_INTHelper switch over to using CVTTS?2SI insns when SSE is available? -Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-ftol2.diff Type: application/octet-stream Size: 13256 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120124/bbe252c0/attachment.obj>

On Jan 20, 2012, at 1:58 PM, Joe Groff wrote: > The integer runtime functions (_allmul, _alldiv, etc. for 64-bit > integer arithmetic) all appear 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? X86FloatingPoi...

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