similar to: [LLVMdev] Undefined behavior in Operator class?

On Sat, Oct 6, 2012 at 8:43 PM, Sean Silva <silvas at purdue.edu> wrote: > If I understand correctly, Operator is basically a trivial temporary > object that holds some common functionality for both Instruction and > ConstantExpr. > > It looks to me like Operator is doing something illegal though. For > example, in this member function of class Operator (in >

> I tried removing the method and rebuilding. The resulting compilation errors were easily fixed by changing the few occurrences in: > include/llvm/Support/PatternMatch.h > lib/Analysis/BasicAliasAnalysis.cpp > lib/Analysis/ScalarEvolution.cpp > lib/Analysis/ValueTracking.cpp > lib/CodeGen/ScheduleDAGInstrs.cpp >

>> In this function, the `this` pointer is not pointing at an Operator >> object. That's undefined behavior, right? > > Yes. Well then I guess the next step is how to fix it. Maybe someone with a bit more experience with the Operator code and how it is used could make a suggestion? (I just stumbled upon this code yesterday while doing some refactoring, so I'm not

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Sean Silva > Subject: Re: [LLVMdev] Undefined behavior in Operator class? > > > In this function, the `this` pointer is not pointing at an Operator > > > object. That's undefined behavior, right? > > Yes. > Well then I guess the next step is how to fix it. I tried

> On Feb 12, 2019, at 4:02 AM, Björn Pettersson A via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > (Sorry if this subject already has been discussed, but I could not find any clear rules/recommendations.) > > What would the recommendation be for acronyms (I’ve seen the rule about avoiding them unless they are “well known”, > but sometimes an acronym is useful, and we

I would assume that the proper name in this case is constantExpr, and not CE. This is not really an acronym, but rather a shortcut taken for some unclear reason. > On 12. Feb 2019, at 13:02, Björn Pettersson A via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > (Sorry if this subject already has been discussed, but I could not find any clear rules/recommendations.) > >

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

It very much depends on what is following the code snippit. If the second "if" is guarding a substantial block of code, "constantExpr" might very well be a good name. Otherwise something like "cExpr" or "constExpr" might be fine. In the past when I have seen things like "CE" in the code, it's not always immediately clear to me what it is. I

I now understand that IndVarSimplify.cpp is capable of reproducing array references when the pointer initialization from the array address is found inside the immediately enclosing loop, such that in the following code: int A[20000], B[100], Z; int main() { int i, j, *a, *b; for ( a = &A[0], i = 0; i != 200; i++ ) for ( b = &B[0], j = 0; j != 100; j++

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

Thanks Duncan, Yes, it is a ConstantExpr! Thank you! Now trying to find a clue in ConstantExpr's functions to get that string :-) Regards, Welson On Thu, Jan 26, 2012 at 9:04 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Welson Sun, > > > Hi, if I have some LLVM code like this: > > > > @.str = private unnamed_addr constant [7 x i8]

Hi again, It's partially done. My concern is that it won't be accepted as is because of adding the flag parameter in a lot of places. I'd like to show what it looks like (here, not on llvm-commit yet), maybe someone could suggest a better way. There are two sources of the flag: field of TargetOptions and function attribute. I had to add the later one for InstCombine pass. Still

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

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 Thu, 17 Jun 2004, Vladimir Prus wrote: > I'm having problems with the following LLVM instruction > > %tmp.0.i = call int (sbyte*, ...)* > %printf( sbyte* getelementptr ([11 x sbyte]* %.str_1, long 0, ...... > > The first argument in function call, > > sbyte* getelementptr ([11 x sbyte]* %.str_1..... > > appears to be ConstantExpression*, and my

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

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 0, i64 0)" in second case can be obtained by dump'ing I.getOperand(0)

Hello, I'm having problems with the following LLVM instruction %tmp.0.i = call int (sbyte*, ...)* %printf( sbyte* getelementptr ([11 x sbyte]* %.str_1, long 0, ...... The first argument in function call, sbyte* getelementptr ([11 x sbyte]* %.str_1..... appears to be ConstantExpression*, and my backend does not support ConstantExpression yet. I probable can implement

Hi During a pass, the XCore target lowers thread local global variables by turning them into global variable arrays indexed by the (max 8) thread ID. (see XCoreLowerThreadLocal.cpp) This works fine for instructions e.g. GetElementPtrInst But can't be done for constants e.g. GetElementPtrConstantExpr Thus I would like to replace GetElementPtrConstantExpr with GetElementPtrInst when it is