similar to: [LLVMdev] InstCombine strips the inBounds attribute in GetElementPtr ConstantExpr

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

I noticed a change in LLVM's behavior between 3.2 and 3.3/ToT, but I'm not sure if it qualifies as a bug/regression or not. The change is that in 3.3 and tip of trunk, calling ConstantFoldConstantExpression on i64 and (i64 add (i64 add (i64 ptrtoint (i64* getelementptr (i64* null, i32 1) to i64), i64 ptrtoint (i64* getelementptr (i64* null, i32 1) to i64)), i64 15), i64 -16)

Adam, I just fixed this issue a few days ago. A version from the trunk should work for you. Cheers, Nadav -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of ihusar Sent: Tuesday, February 15, 2011 15:52 To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] How to use ConstantFoldConstantExpression? I forgot to mention, that I use

On Thu, Oct 28, 2010 at 3:47 PM, Joel E. Denny <jdenny at etinternational.com> wrote: > For example, for my platform, llc folds the add but not the getelementptr > in: > >  @a = global i8* getelementptr (i8* null, i64 add (i64 3, i64 2)) This gets folded when it's read in; there's no other way to represent a constant 'i64 add (i64 3, i64 2)' in LLVM than 'i64

I forgot to mention, that I use LLVM release 2.8, I did not try it with the latest revision, but I expect that I am rather doing something wrong than using non-implemented functions. On Tue, 15 Feb 2011 14:09:57 +0100, ihusar <ihusar at fit.vutbr.cz> wrote: > Hello, > > i need to fold constants, i found that a function ConstantFoldConstantExpression could be used, > however

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

Hello, i need to fold constants, i found that a function ConstantFoldConstantExpression could be used, however I am not able to make it fold anything. Could you please give me some advice, what I am doing wrong? My code looks something like this: //data layout is obtained from clang-generated code for triple arm-none-linux-gnueabi with added v32:32:32 const char* const TARGET_DATA_LAYOUT =

Hello all, >From what I have observed, using `Inst->replaceAllUsesWith` does not replace uses of the `Inst` in `ConstantExpr`s. Is there some way to have a universal replaceAllUsesWith? Thanks, ~Siddharth. -- Sending this from my phone, please excuse any typos! -------------- next part -------------- An HTML attachment was scrubbed... URL:

Following up on the '[LLVMdev] Getelementptr woes' thread: http://mail.cs.uiuc.edu/pipermail/llvmdev/2004-June/001252.html I'm happy to say that Vladimir Prus contributed a constant expression lowering pass for instruction selectors to use. This pass makes instruction selection both easier and less error prone. Thanks Vladimir, and sorry for being such a butthead about it earlier on

Hi LLVMdev members I found something strange in ConstantExpr::replaceUsesOfWithOnConstant() function. in lib/VMCore/Constants.cpp file 2118 if (getOpcode() == Instruction::GetElementPtr) { 2119 SmallVector<Constant*, 8> Indices; 2120 Constant *Pointer = getOperand(0); 2121 Indices.reserve(getNumOperands()-1); 2122 if (Pointer == From) Pointer = To; 2123 2124 for

Hi all, I have got a problem when I used the use_empty() member function while I used a global variable. I erase all the instructions which will use a global variable. Then I called the use_empty() on that global variable. I got no empty because a constantexpr use the global variable. I wonder whether there is any way to erase the constantexpr which is useless to me but occupying the global

Hi, What I'm currently working on is a translation from LLVM IR to a register transfer list format used in VPO. If my understanding of ConstantExpr is correct, that they can be evaluated at compile-time, how can I simply have them be evaluated but have the code still remain in IR format? For example, in: store i32 1, i32* getelementptr [6 x i32]* @arr, i32 0, i32 0 the getelementptr

Hi, I was wondering how exactly LLVM handles the ConstantExpr, specifically GEP ConstantExpr, in code generation. From what I'm reading, translating these Constant Expressions into Instructions can slow the code, so I'd like to be able to handle ConstantExpr in the same way that LLVM code generation does. Thanks, Brandon

Hi all, After 6 months away, I'm looking for some low impact, unimportant area of LLVM to get back in sync with the code base. Is anyone looking at this bug: http://llvm.org/bugs/show_bug.cgi?id=10368 Is it still valid/desired? -- cheers, --renato http://systemcall.org/

Yes, that's definitely still desired. I wouldn't say it is "low impact" though :) -Chris On Apr 14, 2012, at 8:17 AM, Renato Golin wrote: > Hi all, > > After 6 months away, I'm looking for some low impact, unimportant area > of LLVM to get back in sync with the code base. > > Is anyone looking at this bug: http://llvm.org/bugs/show_bug.cgi?id=10368

On Fri, Jun 29, 2012 at 3:10 PM, Renato Golin <rengolin at systemcall.org> wrote: > Hi all, > > It's been a long time, and I'm probably going to kill myself, but I > want to try it anyway. > > Bug 10368 [1] tells me that ConstantExpr shouldn't automatically fold, > and that this is source of many problems (most notably with traps) and > code duplication.

On Fri, 29 Jun 2012 23:10:39 +0100 Renato Golin <rengolin at systemcall.org> wrote: > Hi all, > > It's been a long time, and I'm probably going to kill myself, but I > want to try it anyway. > > Bug 10368 [1] tells me that ConstantExpr shouldn't automatically fold, > and that this is source of many problems (most notably with traps) and > code

On 29 June 2012 23:40, Hal Finkel <hfinkel at anl.gov> wrote: > This seems like yet-another place where target-information integration > would be helpful (and, indeed, should be used). Indeed! And it's part of the plan, to make sure we get it right. However, since all folding will eventually be moved to the function pass, that's gotta be coded (if not there yet) on the pass. I

On Sat, 30 Jun 2012 13:10:47 +0100 Renato Golin <rengolin at systemcall.org> wrote: > On 29 June 2012 23:40, Hal Finkel <hfinkel at anl.gov> wrote: > > This seems like yet-another place where target-information > > integration would be helpful (and, indeed, should be used). > > Indeed! And it's part of the plan, to make sure we get it right. > However,

On Mon, Dec 17, 2012 at 5:10 PM, Yuan Lin <yulin at nvidia.com> wrote: > We cannot use bitcast because bitcast is a value preserving operation, but > the address space conversion operation we have is a bit-changing operation. > > > > Where will the bulk of work be? Can we make a ConstantExpr which has a new > Opcode (or reuse call) and a list of operands? The first