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