similar to: [LLVMdev] Pointers in Load and Store

John, I have looked at the SAFECode and thought following sould work if (isa<Constant>(I.getOperand(0))) { Out << "*** operand 0 is a constant ******"; if (Instruction *operandI = dyn_cast<Instruction>(I.getOperand(0))) { Out << "********operand is an instruction ****"; if (GetElementPtrInst *gepI =

On 1/20/2011 10:02 PM, Surinder wrote: > When I compile C programs into llvm, it produces load instructions in > two different flavours. > > (1) %8 = load i8** %bp, align 8 > > (2) %1 = load i8* getelementptr inbounds ([4 x i8]* @.str, i64 0, > i64 0), align 1 > > I know that %bp in first case and the entire "getelementptr inbounds > ([4 x i8]* @.str, i64

On 1/21/2011 10:46 PM, Surinder wrote: > John, > > I have looked at the SAFECode and thought following sould work > > if (isa<Constant>(I.getOperand(0))) > { Out<< "*** operand 0 is a constant ******"; > if (Instruction *operandI = dyn_cast<Instruction>(I.getOperand(0))) > { Out<<

John, I have looked at the real code (instead of the obsolete one) and it appears to be easy to find if an operand is a getelementptr instruction. if (ConstantExpr * CE = dyn_cast<ConstantExpr>(I.getOperand(0))) { Out<< "*** operand 0 is a constant Expr******"; if (CE->getOpcode() == Instruction::GetElementPtr) { Out<< "*** operand 0 is

Hi all, I am trying to replace all uses of a value1 *inside of a given function* to use value2. My strategy was to iterate all the basic blocks, again iterating all the instructions in each basic block, and using replaceUsesOfWith(value1, value2) for every instruction. This used to work all right, but now I am finding some problems. There are instructions like this: store i32 0, i32*

On 10/21/11 11:15 AM, Carlos Sánchez de La Lama wrote: > Hi all, > > I am trying to replace all uses of a value1 *inside of a given function* > to use value2. My strategy was to iterate all the basic blocks, again > iterating all the instructions in each basic block, and using > replaceUsesOfWith(value1, value2) for every instruction. > > This used to work all right, but

Hi Johannes, > Now that reasoning works from a conceptual standpoint only for > non-inbounds GEPs, I think. From a practical standpoint my above > description will probably make sure everything works out just fine (see > also my rephrased answer down below!). I say this because I think the > following lang-ref passage makes sure everything, not only memory > accesses, involving

Hi Johannes, >> So, the thinking here is: LLVM cannot exclude the possibility of an >> object of size 0 existing at any given address. The pointer returned >> by "GEPi p 0" then would be one-past-the-end of such a 0-sized object. >> Thus, "GEPi p 0" is the identitiy function for any p, it will not >> return poison. > > I don't see the

Hi Johannes, > From the Lang-Ref statement > > "With the inbounds keyword, the result value of the GEP is undefined > if the address is outside the actual underlying allocated object and > not the address one-past-the-end." > > I'd argue that the actual offset value (here 0) is irrelevant. The GEP > value is undefined if inbounds is present and the

Hi, >>> I see. Is there a quick answer to the questions why you need inbounds >>> GEPs in that case? Can't you just use non-inbounds GEPs if you know you >>> might not have a valid base ptr and "optimize" it to inbounds once that >>> is proven? >> >> You mean on the Rust side? We emit GEPi for field accesses and array indexing.

Hi Duncan, Why to break? I wish to analyse all the operands of getelemetptr instructions. For which I iterate over the code and get the instruction of interest by getopcode == getelementptr. But the getelementptrs in this form as in my last mail are getting away from my pass. So i wish to break it. I have a work around if breaking is not possible, but I think it may be a common requirement by

Dear Manish, First, in answer to your original question: yes, there is a pass that will convert constant expression GEPs used within LLVM instructions into GEP instructions. SAFECode has a pass called BreakConstantGEPs in safecode/trunk/lib/ArrayBoundChecks/BreakConstantGEPs.cpp (http://llvm.org/viewvc/llvm-project/safecode/trunk/lib/ArrayBoundChecks/BreakConstantGEPs.cpp?view=log). It

> I had thought that the case that Danny had looked at had a constant GEP, and so this constant might alias with other global pointers. How is that handled now? That issue had to do with that we assumed that for all arguments of a given Instruction, each argument was either an Argument, GlobalValue, or Inst in `for (auto& Bb : Inst.getBasicBlockList()) for (auto& Inst :

----- Original Message ----- > From: "George Burgess IV" <george.burgess.iv at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chandler Carruth" <chandlerc at google.com>, "Jiangning Liu" <Jiangning.Liu at arm.com>, "LLVM Developers Mailing > List" <llvmdev at cs.uiuc.edu>, "Daniel

So, I split it up into three patches: - cflaa-danny-fixes.diff are (some of?) the fixes that Danny gave us earlier for tests + the minimal modifications you’d need to make in CFLAA to make them pass tests. - cflaa-minor-bugfixes.diff consists primarily of a bug fix for Argument handling — we’d always report NoAlias when one of the given variables was an entirely unused argument (We never added

Hi Bruce, On 25.02.19 13:10, Bruce Hoult wrote: > LLVM has no idea whether the address computed by GEP is actually > within a legal object. The "inbounds" keyword is just you, the > programmer, promising LLVM that you know it's ok and that you don't > care what happens if it is actually out of bounds. > >

I am confused by this bit of code in instcombine: 09789 if (GetElementPtrInst *GEPI = dyn_cast<GetElementPtrInst>(Op)) { 09790 const Value *GEPI0 = GEPI->getOperand(0); 09791 // TODO: Consider a target hook for valid address spaces for this xform. 09792 if (isa<ConstantPointerNull>(GEPI0) && 09793

George, given that, can you just build constexpr handling (it's not as easy as you think) as a separate funciton and have it use it in the right places? FWIW, my current list of CFLAA issues is: 1. Unknown values (results from ptrtoint, incoming pointers, etc) are not treated as unknown. These should be done through graph edge (so that they can be one way, otherwise, you will unify

----- Original Message ----- > From: "George Burgess IV" <george.burgess.iv at gmail.com> > To: "Daniel Berlin" <dberlin at dberlin.org> > Cc: "Chandler Carruth" <chandlerc at google.com>, "Hal Finkel" <hfinkel at anl.gov>, "Jiangning Liu" > <Jiangning.Liu at arm.com>, "LLVM Developers Mailing

Sounds good, I'll reword that comment. Also, the assert you mentioned turned out to be a bad assumption when combined with how I foresee us handling inttoptr/ptrtoint in the future, so I'll just replace it with slightly more robust code. :) Thanks for the feedback, George On Tue, Feb 3, 2015 at 11:30 PM, Hal Finkel <hfinkel at anl.gov> wrote: > Hi George, > > +// Given an