similar to: [LLVMdev] How to differentiate standard libc calls from intrinsics

Thanks Eric, but could you give me a little bit more hints or pointers please? I looked into DebugInfo.h, but I'm still not sure how to start. It sounds like I'd have to somehow manually extract metadata nodes from an instruction. Thanks, JS On Wed, Jan 22, 2014 at 10:14 PM, Eric Christopher <echristo at gmail.com>wrote: > This is likely going to be difficult if possible. I

As of earlier this year, we now explicitly ignore the nonnull attributes that glibc puts on memcpy (and other stdlib functions). I don't know how LLVM feels about dangling or underaligned pointers in particular, but AFAICT, we do try hard to make sure that memcpy(NULL, _, 0) works as the user probably intends. Here's the thread I read about it:

> So, the pointer arguments of memcpy *shall* (a violation of a shall > clause is UB, per §4/2) have valid values, even though the function will > copy zero characters. This is true in C but the question was about LLVM intrinsics. Since the LangRef does not mention any such restriction, I would assume that memcpy(0,0,0) is not UB in LLVM. If it is UB then we must update the LangRef

Hi all, when I call the llvm.memcpy/memmove/memset.* intrinsics, typically I have to pass in valid (non-dangling, non-NULL pointers) of the given alignment. However, to what extent to these rules apply when the count is 0? Concretely (for any variant of the three aforementioned intrinsics): Is it UB to call them on a dangling pointer when count is 0? On a pointer of less than the given

Clang is inserting an llvm.memcpy function call into my program where it does not exist (the code never calls memcpy), is there a particular reason for this? It also looks like it's inserting two other artificial function calls, something to do with llvm.lifetime.start and llvm.lifetime.end, what are these functions and why are they being inserted artificially? Thanks. -------------- next

TLDR: a proposal to add GC-parseable lowering to element atomic memcpy/memmove instrinsics controlled by a new "requires-statepoint” call attribute. Currently llvm.{memcpy|memmove}.element.unordered.atomic calls are considered as GC leaf functions (like most other intrinsics). As a result GC cannot occur while copy operation is in progress. This might have negative effect on GC latencies

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

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

I would like it to always be lowered, I don't want it. On Mon, Mar 5, 2012 at 12:27 PM, Eric Christopher <echristo at apple.com>wrote: > You don't have memcpy or want it to always lower it? > > -eric > > On Mar 5, 2012, at 11:56 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > > Christoph, > > > > Yes, you are correct on the lifetime

Chris Lattner wrote: > On Fri, 11 Mar 2005, Morten Ofstad wrote: >> I am trying to make the FP intrinsics (abs, sin, cos, sqrt) I've added >> work with the X86ISelPattern, but I'm having some difficulties >> understanding what needs to be done. > > Cool. Here are a couple of requests: > > 1. I don't think we need an "llvm.abs" intrinsic

Hi Hal, > If you attach noalias metadata to the memcpy call, it will apply to both the source and destination; we don't have a way to differentiate. It might be true that if you attach both noalias and alias.scope metadata to the call, then querying the call against itself will return NoModRef, but that's really hacky (and, in part, wrong, because the destination still alias with

Hello, I'm getting the impression that I'm misunderstanding something about intrinsics. I have the following reduced testcase in mind: declare void @llvm.memcpy.i32(i8*, i8*, i32, i32) nounwind define void @foo(i8* %a, i8* %b, i32 %c, i32 %d) { entry: ;call void @llvm.memcpy.i32( i8* %a, i8* %b, i32 %c, i32 %d ) ;call void @llvm.memcpy.i32( i8* %a, i8* %b, i32 0, i32 0 ) ret void

On Fri, 11 Mar 2005, Morten Ofstad wrote: > Hello, > > I am trying to make the FP intrinsics (abs, sin, cos, sqrt) I've added work > with the X86ISelPattern, but I'm having some difficulties understanding what > needs to be done. Cool. Here are a couple of requests: 1. I don't think we need an "llvm.abs" intrinsic at the llvm level. This can be

Hi, all. I have noticed that LLVM supports some Intrinsic Functions such as *"** llvm.sadd.with.overflow"* described in http://llvm.org/docs/LangRef.html#int_sadd_overflow. We can use these functions and needn't define the function bodies. For example, I can manually insert codes: * %res = call {i32, i1} @llvm.sadd.with.overflow.i32(i32 %a, i32 %b) %sum = extractvalue

Thanks for the feedback. I think both of the suggestions are very reasonable. I’ll incorporate them. Given there were no objections for two weeks, I’m going to go ahead with posting individual patches for review. One small question inline: On Sep 28, 2020, at 10:56 AM, Philip Reames <listmail at philipreames.com<mailto:listmail at philipreames.com>> wrote: In general, I am

Hi Hal > By this I assume you mean some new 'nooverlap' metadata? I don't think we have any existing metadata with the correct semantics. I was thinking we could just use the existing noalias metadata. Implicitly, the current llvm.memcpy semantics are "src and dst overlap perfectly or not at all" (perhaps we should update the docs to reflect this if we plan to rely on

You'll need to do the work then. I'd also question why? On most platforms a decent memcpy exists. -eric On Mar 5, 2012, at 12:28 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > I would like it to always be lowered, I don't want it. > > On Mon, Mar 5, 2012 at 12:27 PM, Eric Christopher <echristo at apple.com> wrote: > You don't have memcpy or want it to

Hi all, A quick note just to let people know that as of this past Friday my go at this work has been fully landed. It ended up being a back-burner item, so it took longer than I would have liked to get completed. None the less, the changes made were: 1) The IRBuilders in LLVM, Clang, and Polly were all updated to create only the new form of the memory intrinsics. 2) All LLVM passes to understand

clang generates llvm.memcpy.* intrinsics for our port. Now we are linking a .bc version of the standard library. Do we have to include a version of these intrinsics in the .bc librrary? If yes, do we have some already written version? Or do we have to leave them for llc to convert them in to memcpy and then provide an binary version of lib with these functions ? - Sanjiv

Hi All, I'd like to float two changes to the llvm.memcpy / llvm.memmove intrinsics. (1) Add an i1 <mayPerfectlyAlias> argument to the llvm.memcpy intrinsic. When set to '1' (the auto-upgrade default), this argument would indicate that the source and destination arguments may perfectly alias (otherwise they must not alias at all - memcpy prohibits partial overlap). While the C