search for: constantexpr

...// Constant expressions //===--------------------------------------------------------------------===// /// GetAlignOf constant expr - computes the alignment of a type in a target /// independent way (Note: the return type is an i64). static Constant *GetAlignOf(const Type* Ty) { return ConstantExpr::getAlignOf(Ty); } /// GetSizeOf constant expr - computes the (alloc) size of a type (in /// address-units, not bits) in a target independent way (Note: the return /// type is an i64). /// static Constant *GetSizeOf(const Type* Ty) { return ConstantExpr::getSizeOf(Ty); } /// G...

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 Subject: Re: [...

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 object > for each ConstantExpr that references the one you're changing. A...

...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 `Inst->replaceAllUsesWith` does not > replace > > uses of the `Inst` in `ConstantExpr`s. Is there some way to have a > universal > > replaceAllUsesWith? > > Where are you seeing instructions used in ConstantExprs? That sounds > really dodgy to me. Instructions are horribly non-Constant so I'd have > thought it would be banned (even for technically plausible...

...at gmail.com> wrote: > On Tue, Nov 10, 2009 at 6:10 PM, Talin <viridia at gmail.com> wrote: (A similar esoteric use case is: "which of >> the following two types is larger, 3 x int32 or 2 x {}*? -- i.e. the union >> problem.) The size of a union can be compiled into a ConstantExpr. i.e., (sizeof(T1) > sizeof(T2)) ? sizeof(T1) : sizeof(T2)) Since sizeof(T1) and sizeof(T2) themselves are ConstantExpr's, and so is icmp(ConstantExpr, ConstantExpr) and select (ConstantExpr, ConstantExpr, ConstantExpr). You won't be able to tell which is bigger from your front-end,...

...on, 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 operand is a > string. I would suggest adding a new subclass to Constant; that's closer to the direction we want to be moving in. It'll look somewhat similar to ConstantExpr, but you don't want to mess wi...

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: Yuan Lin Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] target specific ways to extend ConstantExpr On D...

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 ConstantExpr to support some kind of side-effect free in...

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 ConstantExpr can be evaluated at compile-time, so is...

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 ConstantExpr to support some kind...

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

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 ge...

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,...

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

...pp b/lib/Transforms/Utils/SimplifyCFG.cpp index a01f9b0..c5205ce 100644 --- a/lib/Transforms/Utils/SimplifyCFG.cpp +++ b/lib/Transforms/Utils/SimplifyCFG.cpp @@ -267,7 +267,7 @@ static bool DominatesMergePoint(Value *V, BasicBlock *BB, // Non-instructions all dominate instructions, but not all constantexprs // can be executed unconditionally. if (ConstantExpr *C = dyn_cast<ConstantExpr>(V)) - if (C->canTrap()) + if (C->canTrap() || !isSafeToSpeculativelyExecute(V, DL)) return false; return true; } -- 1.8.4 -------------- next part -------------- Subj...

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: <http://lists.llvm.org/pipermail/l...

...> approach >> is to make stuff handle "User"s instead of Instructions. It is >> much more >> compile time efficient to just handle the two forms rather than >> converting >> them back and forth. > With both I assume you mean both GEP instrs and GEP constantexprs? > If so then > yes, I am intending to make it work with both, and that's exactly > why I need > to convert the constantexprs to instructions (Since, unless I'm very > much > mistaken, a gepconstantexpr won't work with an alloca, so I can't > leave them...

...dress 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 adding one target specific expression, it would be better to have a more generic scheme in LLVM. From: Chris Lattner [mailto:clattner at apple.com] Sent: Monday, December 17, 2012 12:48 PM To: Yuan Lin Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] target specific ways to extend C...

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

...eConstInBoundsGEP2_64 > CreateStructGEP > > All of which are very useful. However, ConstExpression only has: > > getGetElementPtr > getGetElementPtr > getInBoundsGetElementPtr > getInBoundsGetElementPtr > > It would be nice if ConstantExpr's GEP-building methods used the > same naming convention and had the same convenience methods as > IRBuilder. (In fact, the naming convention between IRBuilder and the > various Constants.h classes desperately needs to be reconciled, a > point which I am sure everyon...