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

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

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 cases where the
operand's vreg doesn't happen to get mapped to ST0? I'm still a bit
foggy on the internals of X86FloatingPoint.

One thing I noticed is that fptosi and fptoui both seem to always emit
a redundant SSE load/store when SSE is enabled, because of the check
at Target/X86/X86ISelLowering.cpp:7948. Can this 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 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, 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.
> Could this patch ever break in cases where the
> operand's vreg doesn't happen to get mapped to ST0?
Yes, exactly. You need to make some more complicated test cases.
> I'm still a bit
> foggy on the internals of X86FloatingPoint.
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.
> One thing I noticed is that fptosi and fptoui both seem to always emit
> a redundant SSE load/store when SSE is enabled, because of the check
> at Target/X86/X86ISelLowering.cpp:7948. Can this 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?
When SSE is available, x87 registers are only ever used for f80.

/jakob