search for: setlibcallnam

...ng.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 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::SINC...

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::i6...

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

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

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>

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"); >   setLibcallName(RTLIB::SRA_I64, "__llshr"); > > and > >   setOperationAction(ISD::SHL, MVT::i64, Expand); >   setOperationAction(ISD::SRA, MVT::i64, Expand); >   set...

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

...on, Sep 27, 2010 at 5:02 PM, Evzen Muller <evzen.muller at arm.com> wrote: > > To make it easier to review & commit I have split and cleaned-up our > original > "Support for ARM Run-Time ABI" patch, this part adds support for calls which > > can be mapped using setLibcallName. As noted in the earlier thread on this, I'm pretty sure that we need to only apply the AAPCS calling convention to exactly the set of libcalls that you're adding here. Other libcalls outside this set should use the "native" calling convention such as AAPCS-VFP. deep

...orm to whatever the IR's requirements are. That means that even in the case of your backend, the arguments to the intrinsic must be doubles, not their addresses. You can convert the intrinsics to function calls, together with the call frame set up, etc. during instruction selection. Check setLibcallName, setLibcallCallingConv (and related functions) in include/llvm/Target/TargetLowering.h. The Libcall enum is defined in include/llvm/CodeGen/RuntimeLibcalls.h -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Hi, Working on private backend, based on llvm-3.7 Inside lib/Transforms/InstCombine/InstCombineCompares.cpp there is attempt to optimize fabs: if (F->getIntrinsicID() == Intrinsic::fabs || ... switch (I.getPredicate()) { ... case FCmpInst::FCMP_OGT: return new FCmpInst(FCmpInst::FCMP_ONE, CI->getArgOperand(0), RHSC); But CI->getArgOperand(0)

In the first code I see a 'tail call @acos', in the second code I see a tail call @llvm.acos.f32'. (sorry, there should be only one input for acos, I've been trying many libm/libc functions). Not sure why it's called TargetLibraryInfo if it's not in target specific code? It seems that ALL targets use this code, making it generic. Am I missing something here? Basically

Hi, To make it easier to review & commit I have split and cleaned-up our original "Support for ARM Run-Time ABI" patch, this part adds support for calls which can be mapped using setLibcallName. Thanks Evzen -------------- next part -------------- A non-text attachment was scrubbed... Name: arm-rtabi.patch Type: application/octet-stream Size: 6090 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100927/5b5a038b/attachment.obj>

...; >> wrote: >> > >> > To make it easier to review & commit I have split and cleaned-up our >> > original >> > "Support for ARM Run-Time ABI" patch, this part adds support for calls >> which >> > >> > can be mapped using setLibcallName. >> >> As noted in the earlier thread on this, I'm pretty sure that we need >> to only apply the AAPCS calling convention to exactly the set of >> libcalls that you're adding here. Other libcalls outside this set >> should use the "native" calling co...

Hello LLVM-Dev, Most of the processing for i64 and f64 types for our backend are emulation library calls. Some of the library calls are not defined in the RuntimeLibcalls.def Libcall enum so we have to define custom library calls. How is the ideal way of implementing the custom library calls? Providing us with a target backend having a similar functionality would also help us significantly. Say

Hi, I'm trying to emit FP_ROUND f64 -> f32 considering a mips target that only supports single float point operations. The problem is that f32 is considered legal on this target but f64 doesn't and the only way I can codegen this instruction is using setConvertAction(MVT::f64, MVT::f32, Expand), which issues a EmitStackConvert. What if I want a libcall instead? What should I do? The

Hi, I'm trying to generate some SPARCv8 assembly for a sparc target that doesn't have an FPU. I'm unable to get the flow to generate calls to a soft-float library. Since I wasn't able to find a definitive answer, I was hoping someone might be able to offer some pointers or shed some light. Running "clang -c -emit-llvm -msoft-float test.c -o test.bc" doesn't generate