1*06f32e7eSjoerg//===---------------------------------------------------------------------===// 2*06f32e7eSjoerg// Random ideas for the X86 backend: FP stack related stuff 3*06f32e7eSjoerg//===---------------------------------------------------------------------===// 4*06f32e7eSjoerg 5*06f32e7eSjoerg//===---------------------------------------------------------------------===// 6*06f32e7eSjoerg 7*06f32e7eSjoergSome targets (e.g. athlons) prefer freep to fstp ST(0): 8*06f32e7eSjoerghttp://gcc.gnu.org/ml/gcc-patches/2004-04/msg00659.html 9*06f32e7eSjoerg 10*06f32e7eSjoerg//===---------------------------------------------------------------------===// 11*06f32e7eSjoerg 12*06f32e7eSjoergThis should use fiadd on chips where it is profitable: 13*06f32e7eSjoergdouble foo(double P, int *I) { return P+*I; } 14*06f32e7eSjoerg 15*06f32e7eSjoergWe have fiadd patterns now but the followings have the same cost and 16*06f32e7eSjoergcomplexity. We need a way to specify the later is more profitable. 17*06f32e7eSjoerg 18*06f32e7eSjoergdef FpADD32m : FpI<(ops RFP:$dst, RFP:$src1, f32mem:$src2), OneArgFPRW, 19*06f32e7eSjoerg [(set RFP:$dst, (fadd RFP:$src1, 20*06f32e7eSjoerg (extloadf64f32 addr:$src2)))]>; 21*06f32e7eSjoerg // ST(0) = ST(0) + [mem32] 22*06f32e7eSjoerg 23*06f32e7eSjoergdef FpIADD32m : FpI<(ops RFP:$dst, RFP:$src1, i32mem:$src2), OneArgFPRW, 24*06f32e7eSjoerg [(set RFP:$dst, (fadd RFP:$src1, 25*06f32e7eSjoerg (X86fild addr:$src2, i32)))]>; 26*06f32e7eSjoerg // ST(0) = ST(0) + [mem32int] 27*06f32e7eSjoerg 28*06f32e7eSjoerg//===---------------------------------------------------------------------===// 29*06f32e7eSjoerg 30*06f32e7eSjoergThe FP stackifier should handle simple permutates to reduce number of shuffle 31*06f32e7eSjoerginstructions, e.g. turning: 32*06f32e7eSjoerg 33*06f32e7eSjoergfld P -> fld Q 34*06f32e7eSjoergfld Q fld P 35*06f32e7eSjoergfxch 36*06f32e7eSjoerg 37*06f32e7eSjoergor: 38*06f32e7eSjoerg 39*06f32e7eSjoergfxch -> fucomi 40*06f32e7eSjoergfucomi jl X 41*06f32e7eSjoergjg X 42*06f32e7eSjoerg 43*06f32e7eSjoergIdeas: 44*06f32e7eSjoerghttp://gcc.gnu.org/ml/gcc-patches/2004-11/msg02410.html 45*06f32e7eSjoerg 46*06f32e7eSjoerg 47*06f32e7eSjoerg//===---------------------------------------------------------------------===// 48*06f32e7eSjoerg 49*06f32e7eSjoergAdd a target specific hook to DAG combiner to handle SINT_TO_FP and 50*06f32e7eSjoergFP_TO_SINT when the source operand is already in memory. 51*06f32e7eSjoerg 52*06f32e7eSjoerg//===---------------------------------------------------------------------===// 53*06f32e7eSjoerg 54*06f32e7eSjoergOpen code rint,floor,ceil,trunc: 55*06f32e7eSjoerghttp://gcc.gnu.org/ml/gcc-patches/2004-08/msg02006.html 56*06f32e7eSjoerghttp://gcc.gnu.org/ml/gcc-patches/2004-08/msg02011.html 57*06f32e7eSjoerg 58*06f32e7eSjoergOpencode the sincos[f] libcall. 59*06f32e7eSjoerg 60*06f32e7eSjoerg//===---------------------------------------------------------------------===// 61*06f32e7eSjoerg 62*06f32e7eSjoergNone of the FPStack instructions are handled in 63*06f32e7eSjoergX86RegisterInfo::foldMemoryOperand, which prevents the spiller from 64*06f32e7eSjoergfolding spill code into the instructions. 65*06f32e7eSjoerg 66*06f32e7eSjoerg//===---------------------------------------------------------------------===// 67*06f32e7eSjoerg 68*06f32e7eSjoergCurrently the x86 codegen isn't very good at mixing SSE and FPStack 69*06f32e7eSjoergcode: 70*06f32e7eSjoerg 71*06f32e7eSjoergunsigned int foo(double x) { return x; } 72*06f32e7eSjoerg 73*06f32e7eSjoergfoo: 74*06f32e7eSjoerg subl $20, %esp 75*06f32e7eSjoerg movsd 24(%esp), %xmm0 76*06f32e7eSjoerg movsd %xmm0, 8(%esp) 77*06f32e7eSjoerg fldl 8(%esp) 78*06f32e7eSjoerg fisttpll (%esp) 79*06f32e7eSjoerg movl (%esp), %eax 80*06f32e7eSjoerg addl $20, %esp 81*06f32e7eSjoerg ret 82*06f32e7eSjoerg 83*06f32e7eSjoergThis just requires being smarter when custom expanding fptoui. 84*06f32e7eSjoerg 85*06f32e7eSjoerg//===---------------------------------------------------------------------===// 86