similar to: [LLVMdev] GPU back-ends?

Thanks everyone, a set of wrapper routines it will be then. Dustin, are the routines you wrote open source or do you know if there is already a project that provides such a portable interface to libc for LLVM? If not, I'll write my own routines, but if there is a way to adopt a common standard or avoid reinventing the wheel I'm all for it. Mike

Hello Dustin, Always inline is the closest to a preprocessor macro you can get in LLVM Assembly since it doesn't have a preprocessor at all. LLVM does aggressive inlining for functions used only once so those instances don't require specification as alwaysinline. --Sam ----- Original Message ---- > From: Dustin Laurence <dllaurence at dslextreme.com> > Cc: llvmdev at

On 01/11/2010 11:20 AM, Jeffrey Yasskin wrote: > Awesome, thanks! Committed as r93170 with the following change: > > s/local variables/registers/. "Local variable" refers to allocas in > LLVM, rather than %whatever SSA "variables". Excellent. I was not actually happy with that term when I wrote it, but wasn't sure of the standard terminology. It should

On 01/02/2010 11:24 AM, Bob Wilson wrote: > Yes, that is correct. It is supported in the trunk sources, but it has > not yet been released. Hmm. Would the same also be true of the "inbounds" keyword for GEP? It doesn't seem to be recognized ("expected type"). Dustin

Here is a patch that cleans up a couple of bugs and makes what I think are a couple of small improvements based on the recent advice about structs that I got. There is more like this that could be done, but I wanted to see how this example was received. Dustin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: LangRef.struct.patch URL:

On 01/08/2010 09:17 PM, Nick Lewycky wrote: > Try using 'internal' linkage instead of 'linkonce'. That did it, thanks. --- gemini:~/Projects/LLVM/Tests/Inline(0)$ cat testInline.optdis.ll ; ModuleID = 'testInline.optbc' define i32 @main(i32 %argc, i8** nocapture %argv) nounwind readnone { ret i32 42 } gemini:~/Projects/LLVM/Tests/Inline(0)$ --- > If you're

On Sat, Jan 2, 2010 at 2:31 PM, Dustin Laurence <dllaurence at dslextreme.com> wrote: > On 01/02/2010 11:24 AM, Bob Wilson wrote: > >> Yes, that is correct.  It is supported in the trunk sources, but it has >> not yet been released. > > Hmm.  Would the same also be true of the "inbounds" keyword for GEP?  It > doesn't seem to be recognized

On Sat, Jan 9, 2010 at 12:57 PM, Dustin Laurence <dllaurence at dslextreme.com> wrote: > I have yet another question that I believe also stems from deep > ignorance of the linkage types.  How do you declare a global variable > without defining it?  The IR ref. clearly indicates that you can do > this, but it looks like one of the many "too obvious to mention" things

Awesome, thanks! Committed as r93170 with the following change: s/local variables/registers/. "Local variable" refers to allocas in LLVM, rather than %whatever SSA "variables". On Mon, Jan 11, 2010 at 1:28 AM, Dustin Laurence <dllaurence at dslextreme.com> wrote: > Here is a patch that cleans up a couple of bugs and makes what I think > are a couple of small

Hello Dustin, Alwaysinline is not a hint. It forces something inline that wouldn't have otherwise been as long as the linkage type permits it. (You just ran into a situation where linkage did not permit it.) Personally, I don't see the need for a preprocessor in most circumstances. If you need to do type substitution you can use an opaque type. The only reason for conditional

I have yet another question that I believe also stems from deep ignorance of the linkage types. How do you declare a global variable without defining it? The IR ref. clearly indicates that you can do this, but it looks like one of the many "too obvious to mention" things that I struggle with. It's easy with functions, of course: "declare @foo" in the header and

On 02/12/2010 09:51 AM, Chris Lattner wrote: > I think that the point is that you can define your own standard runtime interfaces: > > void *myopen(const char*path) { > return fopen(path, ...); > } Maybe my experience hand-coding LLVM will actually be of some help. What I did for this case is what I think Chris is suggesting--I have a .c file with functions that return

On 01/09/2010 10:00 AM, Samuel Crow wrote: > > Always inline is the closest to a preprocessor macro you can get in > LLVM Assembly since it doesn't have a preprocessor at all. Mine does. :-) > ...LLVM does > aggressive inlining for functions used only once so those instances > don't require specification as alwaysinline. What I'm trying to do is understand the

Portable OpenCL aims to be an efficient open source (MIT-licensed) implementation of the OpenCL 1.2 standard. In addition to producing an easily portable open source OpenCL implementation, another major goal of the project is improving performance portability of OpenCL programs with compiler optimizations, reducing the need for target-dependent manual optimizations. At the core of pocl is the

On 04/29/2012 01:21 AM, Justin Holewinski wrote: > > > On Sat, Apr 28, 2012 at 8:27 AM, Tobias Grosser <tobias at grosser.es > <mailto:tobias at grosser.es>> wrote: > regalloc= is different. It is global and consequently influences > both host and device code generation. However, to me it is rather a > debugging option. It is never set by clang and

Technically, it could've sent the mail before you even thought about writing it. Undefined is undefined, there are no requirements. From: Dustin Laurence Sent: Wednesday, April 20, 2011 6:50 AM To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Is this a bug in clang? On 04/19/2011 10:50 PM, John Regehr wrote: > The compiler is perfectly within its rights to send a rude email to your >

On Tue, Apr 23, 2013 at 11:57:44PM +0200, Francisco Jerez wrote: > Tom Stellard <tom at stellard.net> writes: > >[...] > > Hi Francisco, > > > > Hi Tom, > > > I would be happy to be a mentor for this project if it is accepted. I > > have a few comments about your proposal: > > > Great. > > >> I'm attaching a preliminary

just want to run some OpenCL software in Wine... but found this blog: http://www.streamcomputing.eu/blog/2011-01-21/opencl-under-wine/ apps like: http://gpuimpulsereverb.de/ Flaccl http://www.hydrogenaudio.org/forums/index.php?showtopic=64628&st=275#entry767843 installed dev drivers 270 and latest 280 drivers for linux../nvidia installed Intel OpenCL1.1 sdk OpenCL CPU works...

On Tue, Apr 23, 2013 at 05:14:46PM +0200, Francisco Jerez wrote: > Francisco Jerez <currojerez at riseup.net> writes: > > >[...] > > Pity not to see any interest in this since I brought up the idea two > > weeks ago. I've uploaded a first attempt at writing a TGSI back-end > > here [2]. It's able to generate code -- though only in assembly form >

Hi guys, I am understanding OpenCL compilation flow on GPU in order to develop OpenCL runtime for a new hardware. I understood that OpenCL compiler is part of a vendor's runtime library which is the heart of OpenCL. Since OpenCL kernel is compiled at runtime, hence at high level its compilation takes place in two steps: i. source code is first converted to intermediate code. ii.