[llvm-commits] [llvm] [PATCH] fpround libcall

[Evan Cheng]

Also, it might be cleaner to just call ExpandOp. I'd hate to have 2  
places that generate the same libcall.

Evan

On Jul 7, 2008, at 6:16 PM, Evan Cheng wrote:

> +      } else if (SrcVT == MVT::f64 && DstVT == MVT::f32 &&
>
> The check for DstVT == MVT::f32 is unnecessary. I would turn it into
> an assertion instead.
>
> +                 getTypeAction(SrcVT) == Expand) {
> +        SDOperand Lo;
> +        Result = ExpandLibCall(RTLIB::FPROUND_F64_F32, Node, false,
> Lo);
> +        break;
>
> I think the patch is alright. But I am not completely comfortable to
> just say yes. Can you do a complete round of testing on x86?
>
> Thanks,
>
> Evan
>
> On Jul 7, 2008, at 5:08 PM, Bruno Cardoso Lopes wrote:
>
>> Hi,
>>
>> This patch address the problem I have with fpround on Mips as
>> discussed at llvmdev. I think this should have been implemented in
>> SoftenFloatOps
>> like suggested by Duncan. The problem is that this methods are only
>> called by
>> "DAG.LegalizeTypes()", which is currently commented in
>> SelectionDAGISel::CodeGenAndEmitDAG. I'll implement there too and
>> see what
>> happens, but what do you think about this for now?
>> Btw, the only target that does setConvertAction from f64 -> f32 to
>> Expand is X86, but
>> in the same code block it declares a f64 Register Class, so i think
>> the patch won't
>> break x86 behavior.
>>
>> Thanks,
>>
>> -- 
>> Bruno Cardoso Lopes
>> http://www.brunocardoso.cc
>> "When faced with untenable alternatives, you
>> should consider your imperative."
>> < 
>> LegalizeDAG.cpp.patch>_______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits