search for: runtimelibcalls

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 for a i64 type compare, does adding it in the RuntimeLibcalls.def enum,...

...l = { relax, acq, rel, acq_rel } and size = {1, 2, 4 , 8, 16}. I am considering two possibilities: i. Atomic Expand pass: add new AtomicExpansionKind::OutOfLine, and if it was set by target expand atomics to RTLIB libcalls. It will require to add 100 new "standardized" library names to RuntimeLibcalls.def and redefine them for Aarch64 target to comply with libgcc implementation ( like this : "cas4_relax" -> " __aarch64_cas4_relax" ) ii. Lower atomics in question later on Instruction Selection pass: for Aarch64 out-of-line atomics targets replace atomicrmw/cmpxchg to __aar...

LLVM appears to support Library functions for ISD::SRA ,ISD::SHL, and ISD::SRL, as they are properly defined in RuntimeLibCalls.def. The library functions defined in RuntimeLibCalls.def (among others) are these: HANDLE_LIBCALL(SRA_I16, "__ashrhi3") HANDLE_LIBCALL(SRA_I32, "__ashrsi3") HANDLE_LIBCALL(SRA_I64, "__ashrdi3") However, setting setOperationAction(ISD::SRA, MVT::i16, LibCall); in...

Current precent in the codebase is the __sync_* libcalls. They have essentially the semantics you want, except that they're all seq_cst. On the LLVM side, I'd rather not have two ways to do the same thing, so I'd prefer to extend the existing mechanism. Adding 100 lines to RuntimeLibcalls.def seems a bit unfortunate, but I think you can reduce that using some C macros. On the compiler-rt side, given the large number of functions, some CMake magic might be appropriate. -Eli -----Original Message----- From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Pavel Ilii...

...: Monday, June 10, 2019 8:31 AM > To: llvm-dev <llvm-dev at lists.llvm.org> > Subject: [EXT] [llvm-dev] Bug: Library functions for ISD::SRA, ISD::SHL, and ISD::SRL > > LLVM appears to support Library functions for ISD::SRA ,ISD::SHL, and ISD::SRL, as they are properly defined in RuntimeLibCalls.def. > > The library functions defined in RuntimeLibCalls.def (among others) are these: > > HANDLE_LIBCALL(SRA_I16, "__ashrhi3") > HANDLE_LIBCALL(SRA_I32, "__ashrsi3") > HANDLE_LIBCALL(SRA_I64, "__ashrdi3") > > However, setting > >...

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

...lvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > Subject: [EXT] [llvm-dev] Bug: Library functions for ISD::SRA, ISD::SHL, and ISD::SRL > > LLVM appears to support Library functions for ISD::SRA ,ISD::SHL, and ISD::SRL, as they are properly defined in RuntimeLibCalls.def. > > The library functions defined in RuntimeLibCalls.def (among others) are these: > > HANDLE_LIBCALL(SRA_I16, "__ashrhi3") > HANDLE_LIBCALL(SRA_I32, "__ashrsi3") > HANDLE_LIBCALL(SRA_I64, "__ashrdi3") > > However, setting > >...

...(disable_call_synthesis)) David what do you think about the additional version that restrict the effect to a few named functions? > e.g. __attribute__((disable_call_synthesis("memset", "memcpy", "sqrt"))) A warning should be issued if the arguments are not part of RuntimeLibcalls.def. Also I'd like to get your take on whether it makes sense to have this attribute apply to functions only or at module level as well. Thx, Guillaume On Mon, Apr 29, 2019 at 10:48 AM David Chisnall via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 26/04/2019 12:47, Guillaume...

Trying to sum-up the approaches that have been discussed, numbered in the order I saw them: 1) Mangle internal names to avoid collisions. 2) Only optimize library functions when they have external linkage. 3) Switch optimizations to do cloning rather than mutating functions 4) Mark all library functions declared in system headers with some attribute and key optimizations on this #1

Is the llvm backend (legalize, isel, etc.) currently capable of handling type f128? I am trying to emit a call to __subtf3 when I compile the following bitcode: define fp128 @f1(fp128 %a0, fp128 %a1) nounwind readnone { entry: %sub = fsub fp128 %a0, %a1 ret fp128 %sub } This is for the Mips backend.

*TL;DR:* Defining memory functions in C / C++ results in a chicken and egg problem. Clang can mutate the code into semantically equivalent calls to libc. None of `-fno-builtin-memcpy`, `-ffreestanding` nor `-nostdlib` provide a satisfactory answer to the problem. *Goal* Create libc's memory functions (aka `memcpy`, `memset`, `memcmp`, ...) in C++ to benefit from compiler's knowledge and

It may not be a full solution for the problems you're trying to solve, but I don't know why adding to include/llvm/CodeGen/RuntimeLibcalls.def is a problem in itself. Certainly, it's a mess that could be organized, especially so we're not repeating everything for each data type as we do right now. So yes, I think that would allow us to remove the VecLib mappings because we are always waiting until codegen to make the translat...

...n at intel.com>; > dccitaliano at gmail.com > *Subject:* Re: [llvm-dev] [RFC][VECLIB] how should we legalize VECLIB > calls? > >   > > It may not be a full solution for the problems you're trying to solve, > but I don't know why adding to > include/llvm/CodeGen/RuntimeLibcalls.def is a problem in itself. > Certainly, it's a mess that could be organized, especially so we're > not repeating everything for each data type as we do right now. > >   > > So yes, I think that would allow us to remove the VecLib mappings > because we are always waitin...

I filed https://bugs.llvm.org/show_bug.cgi?id=42273 last night, about an inconsistency between LTO and non-LTO workflows. The basic scenario is that we have an object file which calls a function "foo", a static library that provides an implementation of "foo", and a shared library that also provides an implementation of "foo". Currently, whether lld chooses the

Adding to Ashutosh's comments, We are also interested in making LLVM generate vector math library calls that are available with glibc (version > 2.22). reference: https://sourceware.org/glibc/wiki/libmvec Using the example case given in the reference, we found there are 2 vector versions for "sin" (4 X double) with same VF namely _ZGVcN4v_sin (avx) version and _ZGVdN4v_sin

...doSourceValue.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/RegAllocRegistry.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/RegisterCoalescer.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/RegisterScavenging.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/RuntimeLibcalls.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/ScheduleDAG.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/ScheduleHazardRecognizer.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/SchedulerRegistry.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/SelectionDAG...

On Thu, Sep 30, 2010 at 3:08 PM, Samuel Williams <space.ship.traveller at gmail.com> wrote: > Hi, > > I might just be doing something stupid, but when I do > > $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. > $ sudo make install > > I don't get the expected headers in >        /usr/local/llvm-2.8/include/llvm > > It is

Hi, I might just be doing something stupid, but when I do $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. $ sudo make install I don't get the expected headers in /usr/local/llvm-2.8/include/llvm It is simply an empty directory. What am I doing wrong? This is on Mac OS X, CMake 2.8+ Kind regards, Samuel