search for: lifetime_end

...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't quite understand how I set up the mapping from the new outputs of some BBs to the new inputs of other BBs. I dug through the code and it lo...

...ly one resume block and one terminate block per function. To get tighter bounds for the strings' lifetimes, I'm considering attaching lifetime.end metadata to the destructor calls in clang: invoke void @foo("basic_string"* %str) to label %eh.resume unwind label %terminate.lpad, !lifetime_end !10 !10 = !{i32 0} SelectionDAGBuilder will then insert a lifetime.end node if there is a lifetime.end attached to an invoke instruction. Does this sound like a reasonable approach? Or are there better ways to tell the backend that the lifetimes do not overlap? -------------- next part ---------...

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?

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 instruction are lifet...

...here. Eventually it should use them to optimize > the > // scalar values produced. > if (IntrinsicInst *II = dyn_cast<IntrinsicInst>(I)) { > assert(II->getIntrinsicID() == Intrinsic::lifetime_start || > II->getIntrinsicID() == Intrinsic::lifetime_end); > II->eraseFromParent(); > continue; > } > > we need to go through the various places that might delete these > intrinsics and fix them. The same will be true with any other mechanism. > It removes them because it does (or will) remove the associated...

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

> > 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, 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 ?

...to them) here. Eventually it should use them to optimize > > the > > // scalar values produced. > > if (IntrinsicInst *II = dyn_cast<IntrinsicInst>(I)) { > > assert(II->getIntrinsicID() == Intrinsic::lifetime_start || > > II->getIntrinsicID() == Intrinsic::lifetime_end); > > II->eraseFromParent(); > > continue; > > } > > > > we need to go through the various places that might delete these > > intrinsics and fix them. The same will be true with any other > > mechanism. > > > > > > > > It removes...