similar to: [LLVMdev] mem2reg for non entry blocks?

Hi Vinod, On 23/02/13 02:20, Vinod Grover wrote: > Sorry if this has been discussed before, but I would appreciate any pointers. > I am trying to understand why mem2reg only looks at allocas in entry blocks, and > not for any allocas in a function. One case where allocas could be used to build > local data structures like linked list (and so on make it unsafe), and for that > the

On Tue, Feb 26, 2013 at 5:42 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Vinod, > > > On 23/02/13 02:20, Vinod Grover wrote: > >> Sorry if this has been discussed before, but I would appreciate any >> pointers. >> I am trying to understand why mem2reg only looks at allocas in entry >> blocks, and >> not for any allocas in a function. One

On 2/26/13 8:06 AM, Duncan Sands wrote: > Hi Justin, > >> an alloca outside of the entry block might be inside a loop, in >> which case the >> semantics are that it would allocate more stack space on every >> loop iteration. >> I think some of the optimizers that run later try to move allocas >> into the entry >> block if possible,

The input language is at assembly level, and the location akin to a %temp ( a virtual register if you will) and contains moves from one virtual to another. Though these are not like memory but I could represent them as local variables and do loads and stores; so I dont know how to represent it in C except as local variables. On Thu, May 28, 2009 at 4:06 PM, Mike Stump <mrs at apple.com>

Hi, A way to handle moves is to have an array mapping virtual regs to the llvm instructions which compute them. Then a dr <- sr move can be handled by doing reg_to_inst [dr] = reg_to_inst [sr]. And whenever sr is used as an input to an operation, use reg_to_inst [sr] instead. Zoltan On Fri, May 29, 2009 at 1:23 AM, Vinod Grover <vgrover528 at gmail.com> wrote:

We are working on a new front-end for LLVM IR for a low level language; The input has mov from one scalar to another and we would like to represent these in LLVM IR. being new to LLVM I am not sure if there is a way to represent this since I couldnt find a mov instr. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

Unfortunately that does not work, since the bitcast will generate a convert and the argument of the intrinsic will be a value type i8* and the intrinsics is intended to map to an instruction that accepts only a symbolic. The convert gets hoisted, possibly to a different block, and we would like the symbolic variable to stay as an operand of the intrinsic making it possible to write the correct

Hi Justin, > an alloca outside of the entry block might be inside a loop, in which case the > semantics are that it would allocate more stack space on every loop iteration. > I think some of the optimizers that run later try to move allocas into the entry > block if possible, but in general it is simpler to have the front-end just put > them there in the first

Hello, in the implementation of some analysis, I need to change the program and then invoke Mem2Reg pass. That pass, in turn, requires other analysis, so I must use PassManager. Here's the code I ended up with: bool runOnFunction(llvm::Function& m) { visit(m); ExistingModuleProvider mp(m.getParent());

I was looking at the LLVM IR documentation and was wondering if it is possible to define LLVM intrinsics which might be a pointer to some pre-defined struct or opaque types?If that is possible how would one go about doing that ? Thanks Vinod -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Apr 19, 2012, at 12:46 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Apr 19, 2012, at 11:15 AM, Justin Holewinski wrote: > >> >> From: Evan Cheng [mailto:evan.cheng at apple.com] >> Sent: Thursday, April 19, 2012 10:47 AM >> To: Justin Holewinski >> Cc: llvmdev at cs.uiuc.edu; llvm-commits at cs.uiuc.edu; Vinod Grover >> Subject:

Thanks. This is going in the right direction IMHO. Obviously, please make sure you add comments to the data structure and convert all the targets first. Also, please don't forget to send an email to llvmdev to warn owners of all the out-of-tree targets about the ABI change. Evan On May 15, 2012, at 6:56 AM, Justin Holewinski <jholewinski at nvidia.com> wrote: > In response to this

In our experience, as Owen also suggests, a pragma or a language extension can be avoided by a combination of static and dynamic analysis. We prefer this approach in our compiler ;) Regards, Vinod On Sat, Jan 24, 2015 at 12:09 AM, Owen Anderson <resistor at mac.com> wrote: > Hi Jingyue, > > Have you considered using dynamic uniformity checks? In my experience you > can

Is inlining (which duplicates code) of functions containing OpenCL style barriers legal?or e.g. if you had some changed phase ordering where you had if (cond) { S1; } call user_func() // user_func has a barrier buried inside it. you do tail splitting if (cond) { S1; call user_func() } else { call user_func(); } now you inline -- oops now you might have a problem so do you want

On Jul 13, 2009, at 8:41 PM, Vinod Grover wrote: > I was looking at the LLVM IR documentation and was wondering if it > is possible to define LLVM intrinsics which might be a pointer to > some pre-defined struct or opaque types? > If that is possible how would one go about doing that ? You mean something like FILE*? It's not possible to do that, but you can just define it

On May 28, 2009, at 4:23 PM, Vinod Grover wrote: > The input language is at assembly level, And C makes for an excellent assembler: $ cat s.c main() { volatile register int i, j; i = j; } $ clang -O4 s.c -o - -S ; ModuleID = 's.c' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32- i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-

In response to this discussion, I've prepared the attached patch as an initial prototype for the LowerCall/LowerCallTo change. All of the information currently needed by the back-ends, and the extra information needed by the NVPTX back-end, is now wrapped in a CallLoweringInfo struct. The various SelectionDAG classes have been modified so any calls to TargetLowering::LowerCallTo use this

From: Evan Cheng [mailto:evan.cheng at apple.com] Sent: Thursday, April 19, 2012 10:47 AM To: Justin Holewinski Cc: llvmdev at cs.uiuc.edu; llvm-commits at cs.uiuc.edu; Vinod Grover Subject: Re: [llvm-commits] [PATCH][RFC] Add extra arguments to TargetLowering::LowerCall() so targets have more context in which to construct call chains TargetLowering::LowerCall is already a mess, I would really

On May 28, 2009, at 3:46 PM, Vinod Grover wrote: > We are working on a new front-end for LLVM IR for a low level > language; The input has mov from one scalar to another and we would > like to represent these in LLVM IR. being new to LLVM I am not sure > if there is a way to represent this since I couldnt find a mov instr. Do you know how to do the action you seek in C? If yes,

On Mon, Jul 13, 2009 at 9:12 PM, Vinod Grover<vgrover528 at gmail.com> wrote: > Unfortunately that does not work, since the bitcast will generate a convert > and the argument of the intrinsic will be a value type i8* and the > intrinsics is intended to map to an instruction that accepts only a > symbolic. A value in LLVM normally doesn't have that sort of identity... what