similar to: [LLVMdev] Clang question

Christoph, Yes, you are correct on the lifetime calls, they are just markers for liveness. However, the backend is not optimizing these calls away. I could try to deal with them outside of llvm but I was hoping for a cleaner solution using llvm? On Mon, Mar 5, 2012 at 11:51 AM, Christoph Erhardt <christoph at sicherha.de>wrote: > Hi Ryan, > > the compiler is free to insert

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

Hi Ryan, the compiler is free to insert implicit calls to memcpy(), for instance for assignments from one struct/class variable to another. The same goes for memset(), which may be inserted implicitly for the initialization of local structs or arrays. The good news is that the backend normally optimizes these calls away where possible, replacing them with simple moves - at least as long as the

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 calls, they are just markers for liveness. > > However, the backend is not optimizing these calls away. I could try to deal with them outside of llvm but I was hoping for a cleaner

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

Does -fno-builtin[-memcpy] handle this? --Owen On Mar 5, 2012, at 12:35 PM, Eric Christopher wrote: > 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.

Owen, Clang doesn't accept this as an option; however, it did accept -fno-builtin (the more general for all usage) and this has seemed to work. Thank you. My other question would then be how to lower vector instructions, such as extractelement, insertelement and shufflevector. These should be solved by ld/st/address calculation, correct? This is somewhat of the same problem it seems to

So, let me rephrase, I understand what these functions are, I just want to know why and when they are inserted so that I can make an attempt to remove them, as they are not produced in llvm-gcc, only in clang? On Mon, Mar 5, 2012 at 10:53 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Clang is inserting an llvm.memcpy function call into my program where it > does not exist (the

Memcpy in my experience has been inserted when a struct copy is generated. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Ryan Taylor Sent: Monday, March 05, 2012 11:04 AM To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Clang question So, let me rephrase, I understand what these functions are, I just want to know why and when they are inserted so that

Owen, Nevermind. bb-vectorize causes this optimization I see, I have disabled it. I am still curious though, what is the syntactically correct way to just remove the -memcpy using -fno-builtin, I have tried both -fno-builtin[-memcpy] and the "gcc" version -fno-builtin-memcpy? On Mon, Mar 5, 2012 at 3:00 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > Owen, >

Eric, Ok, thanks, looks like I'll need to figure something out. I was hoping scalarrepl would take care of this for me, but it's not lowering the structure (I haven't look at the opt code to see why, I"m sure there's some valid reason I'm unaware of atm). On Mon, Mar 5, 2012 at 12:35 PM, Eric Christopher <echristo at apple.com>wrote: > You'll need to do

Ahh, this states the problem precisely. Does anyone know if there is active development in this direction? I'd love to be able to use llvm.lifetime.start() / end(). Scott On Fri, Dec 11, 2009 at 12:12 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Hello, Scott > >> I've just started using LLVM for a project I'm working on, and the >> docs seem

Hello Devang, answers are interleaved 2011/12/7 Devang Patel <dpatel at apple.com> > Hello, > > On Dec 7, 2011, at 2:07 AM, Seb wrote: > > > Hi all, > > > > I would like to add an option for LLVM 'opt' to disable a specific > optimization pass from command line. > > > > The idea is to have something like: > > > > opt -O2

Dear R What does NaN mean? I recently did a correlation on a batch of data for some reason it didn't like one column cor(sleep,use="complete.obs") BodyWt BrainWt SlowSleep ParaSleep TotalSleep BodyWt 1.00000000 0.95584875 -0.3936373 -0.07488845 -0.3428373 BrainWt 0.95584875 1.00000000 -0.3867947 -0.07427740 -0.3370815 SlowSleep -0.39363729

> For instance, I figured out that loop-idiom pass has a BUG in > LLVM 2.9, a llvm.memcpy is generated for an overlapping memory region and > then x86 backend reorder loads/store thus generating a BUG. Just for the record it seems this is a bug in your frontend, not in the LLVM backend. The memcpy intrinsic, like the standard memcpy function, requires that the regions be non-overlapping:

On Mon, Mar 5, 2012 at 3:09 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Owen, > >   Nevermind. bb-vectorize causes this optimization I see, I have disabled > it. > >   I am still curious though, what is the syntactically correct way to just > remove the -memcpy using -fno-builtin, I have tried both > -fno-builtin[-memcpy] and the "gcc" version

Hello! At Sony we've seen some serious customer interest in having the 'this' pointer visible throughout an entire function during debugging. However, optimizations may eliminate it after its last use, so we've been looking for a way to artificially extend its liverange to the end of the function. So far, the most compelling way we can think of, and one we have used successfully

There are a few instrinsic functions I would like to remove, is this possible? For example, the llvm.lifetime and llvm.dbg instrinsics? You can't simply iterate over the funciton and remove the call instructions, this causes issues. Is there a known structured way of doing this? -------------- next part -------------- An HTML attachment was scrubbed... URL:

I think I'm one of the few people actually using LLVM's support for garbage collection, and so far I've found it very difficult to generate code that uses llvm.gcroot() correctly. In the current scheme, it is the frontend's responsibility to insure that any intermediate SSA values containing references to garbage collectible objects are copied to stack variables so that the GC

---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Mon, Dec 12, 2011 at 4:58 PM Subject: Re: [LLVMdev] GetElementPtr To: Eli Friedman <eli.friedman at gmail.com> Sorry, So what I'm trying to ask is are the widths given (32, 64) for the index and the offset the widths of the index and offset values or the width of the type they are