search for: makelibcall

In the 2.4 code, it explicitly used 2 Operands to the MakeLibCall function, whereas in 2.5 it only uses 1 Operand. Other functions like pow, cos, sin, only use 1 Operand as I would expect since they are unary functions and div/mul uses two operands as expected. But after looking more closely at the code, I realized my Mistake in thinking that MakeLibCall was...

...Call.getOperand(0); Hi = Call.getOperand(1); } But in 2.4 the function was: void DAGTypeLegalizer::ExpandFloatRes_FADD(SDNode *N, SDValue &Lo, SDValue &Hi) { SDValue Ops[2] = { N->getOperand(0), N->getOperand(1) }; SDValue Call = MakeLibCall(GetFPLibCall(N->getValueType(0), RTLIB::ADD_F32, RTLIB::ADD_F64, RTLIB::ADD_F80, RTLIB::ADD_PPCF128),...

...th two variables (no immediates) with i32 instructions is so complicated that the target (the TI C64x+ family) has libcalls for them. Instructions for i32 shift exist, of course. Thanks for your help. I'll maybe start tearing up the code generator then. (I've already tried just copying the MakeLibCall function from the right class into our *Lowering.cpp and calling it using custom lowering, but some pass doesn't like that; I suspect it's our scheduler.) Regards, Johannes

Hi Micah, > I'm looking at the Legalize code and in 2.5 the above function is: >... > It seems to me that it was switched from a binary function expansion to > a unary function expansion. I don't understand the question. The new code is supposed to do exactly the same thing as the old code. Can you please be more explicit about what you think the problem is. > Is my

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

...s) > with i32 instructions is so complicated that the target (the TI C64x+ > family) has libcalls for them. Instructions for i32 shift exist, of > course. > > Thanks for your help. I'll maybe start tearing up the code generator > then. (I've already tried just copying the MakeLibCall function from the > right class into our *Lowering.cpp and calling it using custom lowering, > but some pass doesn't like that; I suspect it's our scheduler.) > > Regards, > Johannes > _______________________________________________ > LLVM Developers mailing list >...

...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 jus...

On Sat, Jan 7, 2012 at 10:18 AM, Johannes Birgmeier <e0902998 at student.tuwien.ac.at> wrote: > Hello, > > my target has libcall support for long long shifts. I already have the > following lines in my Lowering constructor: > >   setLibcallName(RTLIB::SHL_I64, "__llshl"); >   setLibcallName(RTLIB::SRL_I64, "__llshru"); >  

Hello, my target has libcall support for long long shifts. I already have the following lines in my Lowering constructor: setLibcallName(RTLIB::SHL_I64, "__llshl"); setLibcallName(RTLIB::SRL_I64, "__llshru"); setLibcallName(RTLIB::SRA_I64, "__llshr"); and setOperationAction(ISD::SHL, MVT::i64, Expand); setOperationAction(ISD::SRA, MVT::i64,

Hi Eli, First of all, please I would appreciate that you try to not confuse my limited use of English with stupidity or lack or criteria in other subjects. I’m not English native, so please keep that in mind. You have been significantly helpful in the recent past so please keep on. Interestingly, you made a mention of a related but not identical issue. It is true that most (or all) processors

Hi All, I am looking at a linker error under O2: undefined symbol __lshrdi3 I have two questions here: 1. Does that mean our libgcc (?) doesn't implement __lshrdi3? Or more generally, why I have such linker error? 2. Seems some operations are combined, and replaced with __lshrdi3 call. I am interested in when such libcall will be generated? Could you show me one

Ignore the suggested fix in my earlier post. How about this? diff --git a/lib/Target/X86/X86ISelLowering.cpp b/lib/Target/X86/X86ISelLowering.cpp index 20c81c3..b8ebf42 100644 --- a/lib/Target/X86/X86ISelLowering.cpp +++ b/lib/Target/X86/X86ISelLowering.cpp @@ -1632,10 +1632,11 @@ X86TargetLowering::X86TargetLowering(const X86TargetMachine &TM, if (!Subtarget.is64Bit()) { // These