similar to: [LLVMdev] target specific ways to extend ConstantExpr

On Dec 17, 2012, at 11:26 AM, Yuan Lin <yulin at nvidia.com> wrote: > I am looking for a way to allow ConstantExpr to express target specific operations, which will be used in global initializers. > > The recommended way to extend LLVM IR is using intrinsic functions. But this does not work for ConstantExpr, which the global initializer uses. > > Should we make

The particular case we are looking at is converting a pointer from one address space to another address space. There is one operand and one output, both are the same pointer type, except for their address space. The pointers are of the same size. The operation is a bit-changing operation. We are using intrinsic functions for the instructions. We need a solution for the ConstantExpr. Instead of

On Dec 17, 2012, at 4:23 PM, Yuan Lin <yulin at nvidia.com> wrote: > The particular case we are looking at is converting a pointer from one address space to another address space. There is one operand and one output, both are the same pointer type, except for their address space. The pointers are of the same size. The operation is a bit-changing operation. > We are using intrinsic

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 operand is a string. From: Chris Lattner [mailto:clattner at apple.com] Sent: Monday, December 17, 2012 4:39 PM To:

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

That's an interesting idea. What are the essential differences between the new subclass and ConstantExpr? Will it end up like ConstantExpr? Or you want it to be ConstantExpr 'done right'? Thanks. Yuan -----Original Message----- From: Eli Friedman [mailto:eli.friedman at gmail.com] Sent: Monday, December 17, 2012 5:40 PM To: Yuan Lin Cc: Chris Lattner; llvmdev at cs.uiuc.edu

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. However, I'm a bit lost... There seem to be constant folding in many places like ConstantExpr::get*() uses

I see. Is there a pre-existing way to do this in LLVM? Cheers, ~Siddharth. On Thu, 17 Aug 2017 at 02:12 Craig Topper <craig.topper at gmail.com> wrote: > ConstantExprs are immutable, they can't be changed once they are created. > And a ConstantExpr can reference other ConstantExprs. So replacing all uses > of a Value in a ConstantExpr would require creating a new immutable

Whoops, sorry, I meant "value->replaceAllUsesWith". Should I create a new post with an updated title? Thanks Siddharth On Thu 17 Aug, 2017, 01:05 Tim Northover <t.p.northover at gmail.com> wrote: > On 16 August 2017 at 15:39, (IIIT) Siddharth Bhat via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > From what I have observed, using

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:

Renato Golin wrote: > Hi all, > > It's been a long time, and I'm probably going to kill myself, but I > want to try it anyway. I don't think that turning off folding of constants is the right place to start. To implement this, start by adding new constants that are going to replace the existing ones. A good rule of thumb is "whatever the relocations in a given

Hi, I've been struggling with constantexprs for a bit. I'm working on a pass that transforms global variables to local variables, and in particular the GetElementPtrConstantExpr is a bit troublesome. For my transformation to properly work, a global value should only be used by Instructions, not by ConstantExprs. I was thinking to add a ConstantExpr::replaceWithInstr() virtual method,

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.

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

On Thu, 17 Jun 2004, Patrick Meredith wrote: > How is this done? Everything logical I have tried has failed, here was > one attempt: > > Constant *C = (Constant*) ConstantArray::get(inst2string(I)); //fucnction defined elsewhere > > //generates a correct Global string > GlobalVariable *str = new GlobalVariable(C->getType(), true, >

On Tue, 17 Jun 2008, Matthijs Kooijman wrote: > I've been struggling with constantexprs for a bit. I'm working on a pass that > transforms global variables to local variables, and in particular the > GetElementPtrConstantExpr is a bit troublesome. For my transformation to > properly work, a global value should only be used by Instructions, not by > ConstantExprs. Ok, this

Hi Chris, > > [ Snip replacing constantexprs with instructions ] > Ok, this is not possible in general though, global variable initializers > have to be constants, not instructions. Yeah, so if not all uses can be replaced, my pass will just have to skip the variable. > Is it possible to design the pass to work with both? The general approach > is to make stuff handle

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

Hey everyone, I'd like to add some new constant foldings to ConstantExpr -- in particular ConstantExpr::get(...) and friends. But, I'm having trouble finding the correct place for adding IR tests in the /test directory. Any suggestions? Thanks, Cam -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Talin, > I find that I call the static methods in ConstantExpr a *lot* without going > through IRBuilder - hundreds of times in my frontend. My language generates a > lot of static data - reflection information, trace tables for the garbage > collector, dispatch tables, runtime annotations, static object instances, and so > on. (In fact there's a special helper class