search for: constantexprs

Here's a sketch of what I am proposing for ConstantBuilder. I'd like feedback on naming conventions, doc comments, etc. //===-- llvm/Support/ConstantBuilder.h - Builder for Constants --*- C++ -*-===// // // The LLVM Compiler Infrastructure // // This file is distributed under the University of Illinois Open Source // License. See LICENSE.TXT for details. //

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

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

...v 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 things like > "and(i32 %inst, 0)"). > > Cheers. > > Tim. > -- Sending this from my phone, please excuse any typos...

On Tue, Nov 10, 2009 at 6:41 PM, Kenneth Uildriks <kennethuil 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)

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

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:

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 intrinsic function calls? If we want to work on such a

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

...xpr to support some kind of side-effect free intrinsic function calls? If we want to work on such a patch, what are the things we should look out for? > > http://llvm.org/bugs/show_bug.cgi?id=10368 seems also express this desire. > That PR is still accurate as to the direction I think ConstantExprs should go. What specifically does this target-specific constant need to look like? -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121217/88dcb0ea/attachment.html>

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

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

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:

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

...we make ConstantExpr to support some kind of side-effect free intrinsic function calls? If we want to work on such a patch, what are the things we should look out for? http://llvm.org/bugs/show_bug.cgi?id=10368 seems also express this desire. That PR is still accurate as to the direction I think ConstantExprs should go. What specifically does this target-specific constant need to look like? -Chris ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauth...

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

Talin wrote: > On Mon, Jan 31, 2011 at 10:57 PM, Talin <viridia at gmail.com > <mailto:viridia at gmail.com>> wrote: > > I notice that there's a lot of inconsistency in the various LLVM > classes with respect to convenience methods. Here's some examples: > > For creating GEPS, IRBuilder has: > > CreateGEP (2 overloads) >