llvm dev - Sep 2009 - [LLVMdev] SoftenSetCCOpernads in LegalizeFloatTypes.cpp

While generating a libcall from floating point comparison, it always 
assumes that the return type of those libcalls is i32.
Why not allow Targets to provide the correct return type?

EVT RetVT = MVT::i32;       // <-- here


  SDValue Ops[2] = { LHSInt, RHSInt };
  NewLHS = MakeLibCall(LC1, RetVT, Ops, 2, false/*sign irrelevant*/, dl);
  NewRHS = DAG.getConstant(0, RetVT);
  CCCode = TLI.getCmpLibcallCC(LC1);


I suggest to have a hook TLI.getCmpLibcallRT() on the lines of 
TLI.getCmpLibcallCC()

Does that sound okay?

- Sanjiv

Hi Sanjiv, I think a lot of the softening code assumes you are dealing
with float (32 bits).  So it's not just a matter of changing the libcall
return type.
> While generating a libcall from floating point comparison, it always 
> assumes that the return type of those libcalls is i32.
> Why not allow Targets to provide the correct return type?
> 
> EVT RetVT = MVT::i32;       // <-- here
> 
> 
>   SDValue Ops[2] = { LHSInt, RHSInt };
>   NewLHS = MakeLibCall(LC1, RetVT, Ops, 2, false/*sign irrelevant*/, dl);
>   NewRHS = DAG.getConstant(0, RetVT);
>   CCCode = TLI.getCmpLibcallCC(LC1);
> 
> 
> I suggest to have a hook TLI.getCmpLibcallRT() on the lines of 
> TLI.getCmpLibcallCC()
> 
> Does that sound okay?
I think it should just use a scheme like GetFPLibCall.

Ciao,

Duncan.

Duncan Sands wrote:
> Hi Sanjiv, I think a lot of the softening code assumes you are dealing
> with float (32 bits).  So it's not just a matter of changing the
libcall
> return type.
>
Yes, we are dealing with 32-bits only. But why the cmp libcalls have to 
return a 32-bit value.
e.g. Our libcall for comparing two floats is

  char _eq_f32 (float a, float b);

rather than
 
  long _eq_f32 (float a, float b);


- Sanjiv