search for: fp_to_inthelper

...d 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/20...

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

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

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

...DValue Store2 = DAG.getStore(Store1, dl, DAG.getConstant(0, MVT::i32), + OffsetSlot, NULL, 0); + return BuildFILD(Op, MVT::i64, Store2, StackSlot, DAG); } std::pair<SDValue,SDValue> X86TargetLowering:: -FP_TO_SINTHelper(SDValue Op, SelectionDAG &DAG) { +FP_TO_INTHelper(SDValue Op, SelectionDAG &DAG, bool IsSigned) { DebugLoc dl = Op.getDebugLoc(); - assert(Op.getValueType().getSimpleVT() <= MVT::i64 && - Op.getValueType().getSimpleVT() >= MVT::i16 && + + MVT DstTy = Op.getValueType(); + + if (!IsSigned) { + assert(DstTy...