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

Sanjiv Gupta wrote:

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
  

Why not use TLI.getSetCCResultType () ?

- Sanjiv

Sanjiv Gupta wrote:

Sanjiv Gupta wrote:
  

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
  

Why not use TLI.getSetCCResultType () ?

- Sanjiv

Duncan,
Any thoughts ?
Or am I missing something very obvious here?

- Sanjiv

getSetCCResultType has nothing to do with the result of a libcall; for
example, on x86 it's i8 even though any libcalls like that will return
an i32. You really need a separate method.

-Eli

Attached a patch for adding the said method. I was off the trunk for a
while so it took longer.

- Sanjiv

CmpLibcallRetType.diff (2.15 KB)

Looks fine except for the commented-out line of code.

-Eli