search for: stuses

...t; 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 &gt...

...ter(), 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, ImplicitKill) calls on the expanded MI at all necessary then since X86FloatingPoint seems to manage that all internally? > When SSE is avai...

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

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