search for: fround_f64_f32

...at point operations. The problem is that f32 is considered legal on this target but f64 doesn't and the only way I can codegen this instruction is using setConvertAction(MVT::f64, MVT::f32, Expand), which issues a EmitStackConvert. What if I want a libcall instead? What should I do? The libcall FROUND_F64_F32 is there, but it seems that it cannot be reached without hacking. What should I do to support this? Am I missing something? Thanks, -- Bruno Cardoso Lopes http://www.brunocardoso.cc "When faced with untenable alternatives, you should consider your imperative."

...ions. The problem is that f32 is considered legal on this > target but f64 doesn't and the only way I can codegen this instruction is using > setConvertAction(MVT::f64, MVT::f32, Expand), which issues a EmitStackConvert. > What if I want a libcall instead? What should I do? The libcall FROUND_F64_F32 > is there, but it seems that it cannot be reached without hacking. What > should I do > to support this? Am I missing something? with the new LegalizeTypes infrastructure you could add a method to DAGTypeLegalizer::SoftenFloatOperand which would turn FP_ROUND into a libcall (this logic w...

...ions. The problem is that f32 is considered legal on this > target but f64 doesn't and the only way I can codegen this instruction is using > setConvertAction(MVT::f64, MVT::f32, Expand), which issues a EmitStackConvert. > What if I want a libcall instead? What should I do? The libcall FROUND_F64_F32 > is there, but it seems that it cannot be reached without hacking. What > should I do > to support this? Am I missing something? Is it possible to handle this with a custom expander? -Chris -- http://nondot.org/sabre/ http://llvm.org/