search for: rtlib

...c81c3..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 libcalls are not available in 32-bit. setLibcallName(RTLIB::SHL_I128, nullptr); setLibcallName(RTLIB::SRL_I128, nullptr); setLibcallName(RTLIB::SRA_I128, nullptr); + setLibcallName(RTLIB::MUL_I128, nullptr); } // Combine sin / cos into one node or libcall if possible. if (Subtarget.hasSinCos()) { setLibcallName(RTLIB::SINCOS_F32,...

On Tue, Jun 7, 2016 at 1:57 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Tim, > > Currently, I have to do multiple things: > > 1) create some setLibcallNames in XXXISelLowering.cpp to generate correct > naming for RTLIBS. > 2) lower ISD down to an RTLIB for some calls (and then do solution 1 on > those to get correct names) These solve a related but different - CodeGen - problem. RTLIB libcalls are used when we're not able to select some IR instruction/intrinsic so have to rely on a runtime library hel...

Looks like I have run into the same issue reported in: https://bugs.llvm.org/show_bug.cgi?id=20871 Is there a fix or work-around for it? The bug report seems to be still open. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171005/46c1282d/attachment.html>

Tim, Are you referring to setLibcallName? That is target specific yes but there isn't RTLIB for most of the libm functions, for example, for acos this doesn't apply. Ideally what I would like is to create a libc with functions like acos called something like __xxx_acos that can still be recognized to be optimized. RTLIB is pretty limited but it works fine, I can just use setLibcal...

...en or ISelLowering specify the libs etc..) >> >> >> >> I agree it's not the best place, but one difference is that >> >> TargetLibraryInfo is much more about OSes than architectures. >> >> >> >> > I'm not sure I follow about the RTLIB, I'm able to use an intrinsic >> for >> >> > floor (def int_floor::Intrinsic in IntrinsicsXXX.td) and still use >> RTLIB >> >> > to >> >> > generate the appropriate name for the function (ie __xxx_floor). It >> >> > sounds...

...odeToLibcall because there’s no switch case for any of the Shift instructions. The problem gets solved by just adding switch cases like this (and similar for the other shift instructions): case ISD::SRA: Results.push_back(ExpandIntLibCall(Node, false, RTLIB::SRA_I16, RTLIB::SRA_I16, RTLIB::SRA_I32, RTLIB::SRA_I64, RTLIB::SRA_I128)); I think this is a BUG by omission of necessary switch cases. Similarly, the following ISD codes ISD::CTTZ, ISD::CTLZ, ISD::CTPOP do not def...

what C code would produce the following when soft float is enabled? (RTLIB::UO_F32, "__unordsf2"); (RTLIB::UO_F64, "__unorddf2"); (RTLIB::O_F32, "__unordsf2"); (RTLIB::O_F64, "__unorddf2"); tia. reed

...ng at the Legalize code and in 2.5 the above function is: void DAGTypeLegalizer::ExpandFloatRes_FADD(SDNode *N, SDValue &Lo, SDValue &Hi) { SDValue Call = LibCallify(GetFPLibCall(N->getValueType(0), RTLIB::ADD_F32, RTLIB::ADD_F64, RTLIB::ADD_F80, RTLIB::ADD_PPCF128), N, false); assert(Call.getNode()->getOpcode() == ISD::BUILD_PAIR && "Call lowered wrongly!"); Lo = Call.getOperand(0); Hi = Call...

...r mathlib calls on Linux for > example when we can use the finite versions of the calls. Have a look in > SelectionDAGLegalize::ConvertNodeToLibcall(): > > if (CanUseFiniteLibCall && DAG.getLibInfo().has(LibFunc_log_finite)) > Results.push_back(ExpandFPLibCall(Node, RTLIB::LOG_FINITE_F32, > RTLIB::LOG_FINITE_F64, > RTLIB::LOG_FINITE_F80, > RTLIB::LOG_FINITE_F128, > RTLIB::LOG_FINITE_PPCF128)); &gt...

...) ? Also when I look at the code of TargetLowering::softenSetCCOperands I see that for some condition code it uses getSetCCInverse() and also I am not able to understand the way it groups condition code in switch case for example : case ISD::SETEQ: case ISD::SETOEQ: LC1 = (VT == MVT::f32) ? RTLIB::OEQ_F32 : (VT == MVT::f64) ? RTLIB::OEQ_F64 : RTLIB::OEQ_F128; break; case ISD::SETNE: case ISD::SETUNE: LC1 = (VT == MVT::f32) ? RTLIB::UNE_F32 : (VT == MVT::f64) ? RTLIB::UNE_F64 : RTLIB::UNE_F128; break; here why SETNE and SETUNE is considered same, why SETON...

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

...oid LegalizeSetCC(MVT VT, SDValue &LHS, SDValue &RHS, SDValue &CC, DebugLoc dl) { - LegalizeSetCCOperands(LHS, RHS, CC, dl); + LHS = LegalizeOp(LHS); + RHS = LegalizeOp(RHS); LegalizeSetCCCondCode(VT, LHS, RHS, CC, dl); } SDValue ExpandLibCall(RTLIB::Libcall LC, SDNode *Node, bool isSigned, SDValue &Hi); - SDValue ExpandIntToFP(bool isSigned, MVT DestTy, SDValue Source, DebugLoc dl); SDValue EmitStackConvert(SDValue SrcOp, MVT SlotVT, MVT DestVT, DebugLoc dl); SDValue ExpandBUILD_VECTOR(SDNode *Node); @@...

On 1/30/15 1:17 PM, Saleem Abdulrasool wrote: > Although this has been discussed in the past, I think that given a few > conversations, it seems that it unfortunately needs to be brought up again. > > There seems to be some disagreement over the ideal location of the > unwinder (libunwind). Currently, libunwind resides in a subdirectory of > libc++abi. There seems to be some

...nyone else willing to work with us to try it again? In my opinion, > however, this is a related but different topic from legalization issue. > > > > Sanjay, I think what you are suggesting would work better if we don’t map > math lib calls to VecLib. Otherwise, we’ll have too many RTLIB:VECLIB_ > enums, one from each different math function multiplied by each > vectorization factor --- for each different VecLib. That’s way too many. If > that’s one per different math functions, I’d guess it’s 100+. Still a lot > but manageable. This requires those functions to be liste...

...> TargetLowering::softenSetCCOperands I see that for some condition code it > uses > getSetCCInverse() and also I am not able to understand the way it groups > condition code in switch case for example : > case ISD::SETEQ: > case ISD::SETOEQ: > LC1 = (VT == MVT::f32) ? RTLIB::OEQ_F32 : > (VT == MVT::f64) ? RTLIB::OEQ_F64 : RTLIB::OEQ_F128; > break; > case ISD::SETNE: > case ISD::SETUNE: > LC1 = (VT == MVT::f32) ? RTLIB::UNE_F32 : > (VT == MVT::f64) ? RTLIB::UNE_F64 : RTLIB::UNE_F128; > break; > here why SETNE...

...y, I want to avoid requiring people to link against libunwind+rt+libcxxabi if all they need is libcxx or rt. >> An alternative to fix the libc++ tests on ARM would be to require >> Compiler-RT to be there as well, but, as I said, Clang links gcc_eh >> and gcc_s when you choose --rtlib=compiler-rt, making the exercise >> moot. > Clang's code isn't frozen... ;) I know, I put it there. :) I did it because that was what libgcc required, and I didn't want to make compiler-RT depend on libc++, at least not at a Clang level. Since gcc_s and gcc_eh are both provid...

Hi Daniel, I'm trying to use the feature you added to Clang a long time ago (2011), the --rtlib=compiler-rt and it doesn't seem to do anything. Now that I have compiler-rt building on ARM and the archive libraries under /lib, I'd like to replace -lgcc with -lclang_rt, but this command line: $ clang --rtlib=compiler-rt -Wl,-lclang_rt foo.c Gives me the warning/errors: clang-3.5: war...

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, Expand); setOperationAction(ISD::SRL, MVT::i64, Expa...

Ashutosh, Thanks for the repy. Related earlier topic on this appears in the review of the SVML patch (@mmasten). Adding few names from there. https://reviews.llvm.org/D19544 There, I see Hal's review comment "let's start only with the directly-legal calls". Apparently, what we have right now in the trunk is "not legal enough". I'll work on the patch to stop