search for: lifetime_start

Hello, What intrinsics "@llvm.lifetime.start/@llvm.lifetime.end" really do? As per my knowledge, they define the live ranges of variables. In the following code section, they seem redundant. However, when I remove them, the behavior of the code becomes non-deterministic. The live ranges of the variables defined by them are never used in the code. Thanks, --------------- %37 = bitcast

...someone from the community will be able to offer a little insight so that if there are major issues here I can find out sooner rather than later. I'd like to add this newly-created big vector value as an input reg for all BBs that reference the original stack object but do not contain it's LIFETIME_START node, and I'd like to add it as an output reg for all BBs that reference the original stack object but do not contain it's LIFETIME_END node. I can create Copy From/ToReg nodes easily enough and I think I can get the reg number using MachineRegisterInfo::createVirtualRegister(). But I don...

...> > call void @lifetime.start( %p ) > > > > > > ... use %p > > br i1 %c, label %loop, label %exit > > > > > > For this reason, it has been suggested that these intrinsics are > > horribly broken, > > I disagree, these just seem like bugs. lifetime_start are marked as > IntrReadWriteArgMem, but this is not really sufficient to prevent their > removal should the memory be subsequently unused. Plus there are other > places that just delete the lifetime intrinsics, like this in > lib/Transforms/Scalar/SROA.cpp: > > // FIXME: Cu...

Hi all, I would like my optimization pass to change an object's address space that is created by llvm.lifetime.start intrinsic. Because I want to be able to identify them later in a codegen pass. I can get a pointer from the intrinsic using CallInst::getArgOperand() function. However, I don't know what to do with it (or if it is the pointer that I want). How can I change its address space?

> > This seems fine to me. The optimizer can (soundly) conclude that %p is > dead after the "lifetime.end" (for the two instructions), and dead before > the "lifetime.start" (for the *single* instruction in that basic block, > *not* for the previous BB). This seems like the proper result for this > example, am I missing something? > What if I put that in

Hi, If the special handling in the meg2reg pass is to look for lifetime intrinsics, shouldn't it cast to <IntrisicInst> and then use getInstrinsicID to check for lifetime_start and lifetime_end ? The thing that I don't understand is the following piece of code, which finds all the users and cast it to <Instruction> then eraseFromParent(). How can this guarantee that it only erase lifetime instrinsics ? -guoqing // The only users of this bitcast/GEP inst...

...t; > > > > > > > ... use %p > > > br i1 %c, label %loop, label %exit > > > > > > > > > For this reason, it has been suggested that these intrinsics are > > > horribly broken, > > > > I disagree, these just seem like bugs. lifetime_start are marked as > > IntrReadWriteArgMem, but this is not really sufficient to prevent > > their removal should the memory be subsequently unused. Plus there > > are other places that just delete the lifetime intrinsics, like this > > in lib/Transforms/Scalar/SROA.cpp: > &gt...

----- Original Message ----- > From: "guoqing zhang" <gqzhang81 at gmail.com> > To: llvmdev at cs.uiuc.edu > Sent: Friday, January 30, 2015 4:29:16 AM > Subject: [LLVMdev] About user of bitcast/GEP instruction > > Hi, > > > In PromoteMemoryToRegister.cpp, it seems to rely on the fact that the > only users of bitcast/GEP instruction are lifetime

Hi, In PromoteMemoryToRegister.cpp, it seems to rely on the fact that the only users of bitcast/GEP instruction are lifetime intrinsics (llvm.lifetime.start/end). I did some searching in llvm/test folder, it seems to be true. However, by reading LLVM IR manual, I don't see any restriction stated on the possible user of bitcast/GEP instruction. So my question is who impose the restriction ?

Hi @all, I hit a problem with Polly-generated code which llvm.org/PR32251 . The problem is how @llvm.lifetime.start is placed after Polly transformed the code. Basically Polly transformed llvm.lifetime.start(&var) [...] llvm.lifetime.end(&var) into if (c) { llvm.lifetime.start(&var) } [...] llvm.lifetime.end(&var) now the llvm.lifetime.end is