Displaying 3 results from an estimated 3 matches for "newlhs".
Did you mean:
new_lhs
2009 Sep 29
2
[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
2015 May 05
1
[LLVMdev] Naryreassociate vs reassociate
On Tue, May 5, 2015 at 10:20 AM, Jingyue Wu <jingyue at google.com> wrote:
> Hi Daniel,
>
> I presume you mean, instead of assigning function arguments distinct ranks
> (http://llvm.org/docs/doxygen/html/Reassociate_8cpp_source.html#l00282), we
> should group function arguments in favor of existing pairings.
Existing = pairings reassociate already chose before
*not*
existing
2009 Sep 29
0
[LLVMdev] SoftenSetCCOpernads in LegalizeFloatTypes.cpp
...rating 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...