similar to: [LLVMdev] types allowed for intrinsics?

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

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

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:

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 existing conditions in IsAllocaPromotable (i.e. the alloca pointer cannot

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

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

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

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-

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

> -----Original Message----- > From: Dan Bailey [mailto:dan at dneg.com] > Sent: Sunday, April 29, 2012 8:46 AM > To: Justin Holewinski > Cc: Jim Grosbach; llvm-commits at cs.uiuc.edu; Vinod Grover; > llvmdev at cs.uiuc.edu > Subject: Re: [llvm-commits] [PATCH][RFC] NVPTX Backend > > Justin, > > Firstly, this is great! It seems to be so much further forward in

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

> -----Original Message----- > From: Evan Cheng [mailto:evan.cheng at apple.com] > Sent: Wednesday, May 16, 2012 5:30 PM > To: Justin Holewinski > Cc: llvmdev at cs.uiuc.edu; llvm-commits at cs.uiuc.edu > Subject: Re: [llvm-commits] [PATCH][RFC] Add extra arguments to > TargetLowering::LowerCall() so targets have more context in which to > construct call chains > >

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Justin Holewinski wrote: <blockquote

you can use an add with zero, if you dont think you are adding redundancy. On Thu, May 28, 2009 at 7:35 PM, Zoltan Varga <vargaz at gmail.com> wrote: > 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