llvm dev - Jan 2012 - [LLVMdev] Best way to interface with MSVC _ftol2 runtime function for fptoui?

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 that
> instead, or do I need to replicate the functionality manually as DAG
> nodes?
On second thought, it might not be the best approach to prodice inline asm
during lowering.

How many of these libcalls do you need to implement? What exactly is the calling
convention? Which registers are clobbered etc.

/jakob

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 the return value is given in EDX:EAX. EAX, EDX,
and ST0 are clobbered (the latter by popping the stack). The function
creates a stack frame. It messes with the x87 control word internally,
but the original control word is restored before returning.

-Joe

On Jan 19, 2012, at 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
> of the x87 stack, and the return value is given in EDX:EAX. EAX, EDX,
> and ST0 are clobbered (the latter by popping the stack). The function
> creates 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 its argument, like FISTP64m.

2. Use inline asm. Which is pretty gross. You would need to construct a
SelectionDAG node identical to the one produced by real inline asm. There should
be some help in include/llvm/InlineAsm.h

I am not sure which is worse, but if there are multiple libcalls like this, you
should go with something like 1.

Please investigate if there are other libcalls like this. If so, we should work
out a proper solution instead of the inlineasm hack.

/jakob