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

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

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

Are there any docs for X86FloatingPoint? At a glance the FISTP etc.
definitions look just like the FIST etc. definitions; where is the
stack handled?

-Joe

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?
X86FloatingPoint.cpp with comments is all you get.

/jakob