search for: getlibcallname

...etLibcallName(RTLIB::SINCOS_F32, "sincosf"); This will make the Legalizer choose the brute force approach below: void DAGTypeLegalizer::ExpandIntRes_MUL(SDNode *N, SDValue &Lo, SDValue &Hi) { ... if (LC == RTLIB::UNKNOWN_LIBCALL || !TLI.getLibcallName(LC)) { // We'll expand the multiplication by brute force because we have no other // options. This is a trivially-generalized version of the code from // Hacker's Delight (itself derived from Knuth's Algorithm M from section // 4.3.1). -------------- next part ----------...

...r am I missing something? Thanks! Damien if (!RewindFunction) { LLVMContext &Ctx = Resumes[0]->getContext(); FunctionType *FTy = FunctionType::get(Type::getVoidTy(Ctx), Type::getInt8PtrTy(Ctx), false); const char *RewindName = TLI->getLibcallName(RTLIB::UNWIND_RESUME); RewindFunction = F->getParent()->getOrInsertFunction(RewindName, FTy); } ________________________________ This e-mail and its attachments are intended only for the individual or entity to whom it is addressed and may contain information that is confidential, pr...

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

...n == TargetLowering::Legal && TLI.isTypeLegal(NVT)) || Action == TargetLowering::Custom) { <== False ... } if (N->getOpcode() == ISD::SHL) { <== Branch taken } else if (N->getOpcode() == ISD::SRL) { ... } else { ... } if (LC != RTLIB::UNKNOWN_LIBCALL && TLI.getLibcallName(LC)) { <== Returns False as I set the lib call name to NULL from the target selection lowering constructor ... } if (!ExpandShiftWithUnknownAmountBit(N, Lo, Hi)) { <== Expand returns true ... } Thanks, Javier On Tue, 01 Dec 2009 11:07:21 +0100, Duncan Sands <baldrick at free.fr>...

Hi Javier, > The problem is the implementation of the expansion. Perhaps an example > can help illustrate better. Take the case of a 64-bit integer shifted > left by say 6 bits and is decomposed using 32-bit registers. Because 6 > is less than the 32 (the register size) the resulting low part should be > equal to the source low part shifted left by 6 bits. The current >

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>

Hi Duncan, The problem is the implementation of the expansion. Perhaps an example can help illustrate better. Take the case of a 64-bit integer shifted left by say 6 bits and is decomposed using 32-bit registers. Because 6 is less than the 32 (the register size) the resulting low part should be equal to the source low part shifted left by 6 bits. The current implementation places a zero