search for: getobjectsize

...'t the "object" refer to the entire block of memory being allocated? >> No, the ""llvm.objectsize intrinsic" is defined as the size of the object pointed to by the first argument, in your case "p+50". To implement the llvm.objectsize intrinsic we call getObjectSize on the "p+50" pointer. See http://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html for intended use. >> (char*) p = malloc(56) >> llvm.objectisize.i32(p+50); >> >> Thanks >> Shuxin >> >> >> >> This question is related to P...

...an be assumed "no alias" if the access size of an memory access (i.e. a load or store) is bigger than the underlying object of the other accessed object. For you example below: V1Size = sizeof(mydata) V2Size = say 4 assuming that GetUnderlyingObject for addr1 and addr2 returns mydata: getObjectSize(O1) = sizeof(mydata) getObjectSize(O2) = sizeof(mydata) this should be isObjectSmallerThan(O2, V1Size) == false isObjectSmallerThan(O1, V2Size) == false ?? > > In llvm, the "object pointed to by ptr p" seems to take on two meanings. Suppose the corresponding > clique of...

> In the "llvm.objectsize" context we pass an object "based on p" to getObjectSize: "p+50". In the basicaa context, we wanna know whether an access is beyond the bounds of an underlying object (undefined behavior land) so we pass the underlying object (which in your example would be the "p" returned from malloc) to the getObjectSize function. > > In the...

...memcpy(addr1, ... sizeof(mydata)) // mem1 = load addr2->syz // mem2 -------------------------------------------------------- ( But for the phi node, getUnderlyingObject() would return "mydata" as "object" for both memory accesses. ) getObjectSize(mem2) return 4 instead of sizeof(mydata). Now that the "object" only have 4 bytes, the "object" of another access, which has sizeof(mydata) byte, should not cover this object, and hence mistakenly give "noalias". On 2/27/13 7:41 AM, Arnold Schwaighofer wro...

...f the other accessed object. > > For you example below: > > V1Size = sizeof(mydata) > V2Size = say 4 > > assuming that GetUnderlyingObject for addr1 and addr2 returns mydata: This assumption is wrong. The GetUnderlyingObject() return phi node instead of &mydata. > > getObjectSize(O1) = sizeof(mydata) > getObjectSize(O2) = sizeof(mydata) > > this should be > isObjectSmallerThan(O2, V1Size) == false > isObjectSmallerThan(O1, V2Size) == false > > ?? > >> In llvm, the "object pointed to by ptr p" seems to take on two meanings. Suppos...

...quot;; It does fix the problem. However, I'm wondering in what situations the Offset != 0. So I put an assertion right before line 359, saying "assert(Offset != 0)". It catches two cases in SingleSource test suite. I investigate one of them, the assertion is triggered when the llvm::getObjectSize() is called by instcombine (instead of alias analyizer) in an attempt to replace llvm.objectsize() with a constant. I think the way llvm::getObjectSize() interpret "object" is wrong. Figure 1 cat -n lib/Analysis/MemoryBuiltins.cpp 344 bool llvm::getObjectSize(const Value *Ptr, uin...

...lem. > However, I'm wondering in what situations the Offset != 0. So I put > an assertion right before line 359, > saying "assert(Offset != 0)". It catches two cases in SingleSource > test suite. I investigate one of them, > the assertion is triggered when the llvm::getObjectSize() is called > by instcombine (instead of alias analyizer) > in an attempt to replace llvm.objectsize() with a constant. I think > the way llvm::getObjectSize() interpret "object" is wrong. > > > Figure 1 > cat -n lib/Analysis/MemoryBuiltins.cpp > 344 bool ll...

I’m debugging SAFECode source code files, and in AllocatorInfo.cpp, in the function getObjectSize(Value* V), the function getAnalysis<DataLayout>() is called. I’ve run into this problem before, and the first time I saw it, my employer recommended I use M.getDataLayout() instead, where M was a reference to a Module. However, in getObjectSize(Value* V), there is no Module reference in the...

The documentation of LLVM says that "The llvm.objectsize intrinsic is lowered to a constant representing the size of the object concerned". I'm attempting to lower this intrinsic function to a constant in a pass. Below is the code snippet that I wrote: for (BasicBlock::iterator i = b.begin(), ie = b.end(); (i != ie) && (block_split == false);) { IntrinsicInst *ii =

...ample: func1(...) { ... } func2(...) { ... } Say the first function uses 64 bytes of the stack and an assumed offset of 0 and the second function uses 32 bytes of the stack but an assumed offset of 64. I've found out how to get the size of the stack via MachineFrameInfo.StackSize/getObjectSize, however I have not found out how to determine the starting offset of the stack for that specific function. I need this information so that I can offset my stack pointer correctly since all my indices into my stack need to start at 0 for each independent function call. So, what this means is t...

...mp(); MachineFrameInfo &MFI = *MF.getFrameInfo(); unsigned Align = MFI.getObjectAlignment(MVT::i8); MachineMemOperand *MMO = MF.getMachineMemOperand(MachinePointerInfo::getFixedStack(MVT::i8), MachineMemOperand::MOStore, MFI.getObjectSize(MVT::i8), Align); BuildMI(MBB, MI, DL, get(Picoblaze::STORETOSTACK ));//.addMemOperand(MMO); if (RC == &Picoblaze::GR8RegClass) { // BuildMI(MBB, MI, DL, get(Picoblaze::ADD8ri )) // .addReg(Picoblaze::BP) // .addImm(FrameIdx); BuildMI(MBB...

...ome help with this points. 1. how can we add special code for the Prolog/Epilog for some certain functions, this should be done with machinefunction pass, rt? 2. Basically, I want to get the function stack frame, that is the size and the initial position. I found int64_t llvm::MachineFrameInfo::getObjectSize ( int *ObjectIdx* ) const[inline] This method is done before or after the mapping of virtual registers? 3. the program code will be at .text section, suppose we are going to move the code from .text to somewhere else, how can we get the start and the length of the effective code, Thanks. -- ---...

...->getType()->getPointerElementType()->getPrimitiveSizeInBits(); > > First, you can't always determine the size. Just looking at the pointer > element type isn't enough. This requires finding the object definition, > which can fail, and the existing handling uses llvm::getObjectSize to for. > In general when looking at type sizes you don't want to use > getPrimitiveSizeInBits, and should use the DataLayout for various reasons. > > > Value *result = ConstantInt::get(ii->getType(), bit_size); > ii->replaceAllUsesWith(result); > ii->remo...

...tDebugLoc(); MachineFunction &MF = *MBB.getParent(); MachineFrameInfo &MFI = *MF.getFrameInfo(); MachineMemOperand *MMO = MF.getMachineMemOperand(PseudoSourceValue::getFixedStack(FrameIdx), MachineMemOperand::MOStore, 0, MFI.getObjectSize(FrameIdx), MFI.getObjectAlignment(FrameIdx)); unsigned tmpVReg = MF.getRegInfo().createVirtualRegister(OURTARGET::IntRegsRegisterClass); MachineInstr* mi = BuildMI(MBB, MI, DL, get(OURTARGET::ADDri), tmpVReg).addFrameIndex(FrameIdx).addImm(0); BuildMI(MBB, MI, DL,...

So, I can make all these testcases work, but it's a little tricky (it involves tracking some things, like GEP byte range, and then checking bases and using getObjectSize, much like BasicAA does). Because i really don't want to put that much "not well tested" code in a bugfix, and honestly, i'm not sure we will catch any cases here that BasicAA does not, i've attached a change to XFAIL these testcases, and updated the code to return MayAlias....

Hello, the calculateFrameObjectOffsets methods in CodeGen/PrologEpilogEmitter.cpp does not work for me, since it asserts if stack grows up, and when assert is commented out, allocates spill slots in the same location as function arguments, which is not right. I've tried to fix that, and a patches. It merely adds if (StackGrowsDown) everywhere, so that the current logic should not be

...PM > > Subject: Re: [LLVMdev] question about enabling cfl-aa and collecting a57 > numbers > > > > So, I can make all these testcases work, but it's a little tricky (it > > involves tracking some things, like GEP byte range, and then > > checking bases and using getObjectSize, much like BasicAA does). > > > > > > Because i really don't want to put that much "not well tested" code > > in a bugfix, and honestly, i'm not sure we will catch any cases here > > that BasicAA does not, i've attached a change to XFAIL these &gt...

...about enabling cfl-aa and > > > collecting a57 numbers > > > > > > So, I can make all these testcases work, but it's a little tricky > > > (it > > > involves tracking some things, like GEP byte range, and then > > > checking bases and using getObjectSize, much like BasicAA does). > > > > > > > > > Because i really don't want to put that much "not well tested" code > > > in a bugfix, and honestly, i'm not sure we will catch any cases > > > here > > > that BasicAA does not, i'...

...enabling cfl-aa and > > > collecting a57 numbers > > > > > > So, I can make all these testcases work, but it's a little tricky > > > (it > > > involves tracking some things, like GEP byte range, and then > > > checking bases and using getObjectSize, much like BasicAA does). > > > > > > > > > Because i really don't want to put that much "not well tested" > > > code > > > in a bugfix, and honestly, i'm not sure we will catch any cases > > > here > > > that B...

...lecting a57 numbers >>> > > >>> > > So, I can make all these testcases work, but it's a little tricky >>> > > (it >>> > > involves tracking some things, like GEP byte range, and then >>> > > checking bases and using getObjectSize, much like BasicAA does). >>> > > >>> > > >>> > > Because i really don't want to put that much "not well tested" >>> > > code >>> > > in a bugfix, and honestly, i'm not sure we will catch any cases &gt...