similar to: [LLVMdev] Math Library Intrinsics as native intrinsics

Hi Micah, > There seems to be some math library functions that are already built > into llvm as intrinsic(pow, exp, etc...) but there are lots that are not > built in yet. Is there currently work going on that is implementing > these? I do not want to duplicate work so I want to see what is out > there. another approach is to get rid of the llvm intrinsics, because they don't

On Apr 8, 2009, at 12:43 AM, Duncan Sands wrote: > Hi Micah, > >> There seems to be some math library functions that are already built >> into llvm as intrinsic(pow, exp, etc...) but there are lots that >> are not >> built in yet. Is there currently work going on that is implementing >> these? I do not want to duplicate work so I want to see what is out

Dan, I have a large list of functions(60+) that I want to be legalized. I have currently been adding them in the same manner as pow/exp etc... These functions come in both scalar and vector versions of up to 16 elements as the 1.0 spec requires. Is this something that I could Merge back into the tree or is another approach required? Some of the thoughts we were having as not to clutter the llvm

There's at least one other LLVM user which would find these useful, and probably more, so it may be appropriate to merge this into the main tree. I'm interested to hear if anyone else has an opinion here. An llvm.math namespace seems like a good idea. Instead of using "fpow" though, I'd prefer to just use names like "pow". For consistency, the ISD namespace

On Apr 14, 2009, at 9:46 AM, Dan Gohman wrote: > There's at least one other LLVM user which would find these > useful, and probably more, so it may be appropriate to merge > this into the main tree. I'm interested to hear if anyone > else has an opinion here. I'd rather not see them in the main tree, since there's no real explanation of what the benefits would be

Fair enough, The current issue that I am having with my backend and the language I have to support via LLVM is that: 1) I need to support a large number of math functions as language built-in and not as a separate library. These functions are part of the core language and thus must be supported on a wide-variety of data types with very specific rules and definitions for each function, which in

Hi James, some additional comments regarding some of your questions: Q: Is SPIR meant to be storage-only, or to allow optimizations to be done? I agree with Micah that optimizing a SPIR module might make it less portable. However, SPIR doesn't prohibit optimizations. It is up to the OpenCL optimizer to decide when to "materialize" SPIR to a device specific LLVM module or even

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of James Molloy > Sent: Tuesday, September 11, 2012 8:49 AM > To: Ouriel, Boaz > Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] SPIR provisional specifciation is now available > in the Khronos website > > Hi Boaz, >

Hi Micah, >> (a) You mention special calling conventions and adding them to LLVM. >> What are their semantics? And what is their purpose? > [Villmow, Micah] One purpose is to differentiate between kernel and device functions. > Another is to differentiate between the standard calling conventions that have > device specific assumptions built into them. Do you have an example

Hi James, This is very good feedback. 1. Adding the new calling conventions - It seems like the appropriate thing to do vs. metadata. Some OpenCL backends can choose to implement this calling convention and use it during code generation of OpenCL functions/kernels. Can we agree on this item? 2. Restricting the allowable instructions - As Micah mentioned before, the restrictions are there

Hi Boaz, Micah, Thanks for the followup. > I agree with Micah that optimizing a SPIR module might make it less portable. > However, SPIR doesn't prohibit optimizations. It is up to the OpenCL optimizer to decide when to "materialize" SPIR to a device specific LLVM module or even convert it to another IR. > It would be useful if we could identify areas in the specification

Hi Boaz, David, Thanks for taking my responses on board. > 1. Adding the new calling conventions - It seems like the appropriate thing to do vs. metadata. Some OpenCL backends can choose to implement this calling convention and use it during code generation of OpenCL functions/kernels. Can we agree on this item? Hmm, this is the one I was most shaky on. I still don't fully understand

On Sep 6, 2012, at 4:33 PM, "Ouriel, Boaz" <boaz.ouriel at intel.com> wrote: > **** Introduction **** > Lately, Khronos has ratified a new provisional specification which is called SPIR. > This specification standardizes an intermediate representation for the OpenCL kernel language. > It is based on LLVM infrastructure and this is why I am sending this mail to the

James, here are our updated answers after discussing this. > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of James Molloy > Sent: Tuesday, September 11, 2012 8:49 AM > To: Ouriel, Boaz > Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] SPIR provisional specifciation is now

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Richard Smith Sent: Wednesday, September 12, 2012 1:55 PM To: Ouriel, Boaz Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] SPIR Portability Discussion On Wed, Sep 12, 2012 at 12:27 PM, Ouriel, Boaz <boaz.ouriel at intel.com<mailto:boaz.ouriel at intel.com>> wrote: Hey

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Vikram Adve > Sent: Thursday, September 06, 2012 3:52 PM > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] "SPIR" ? A Standard Portable IR for OpenCL > Kernel Language > > On Sep 6, 2012, at 4:33 PM, "Ouriel, Boaz"

So for us we use SLEEF to actually implement the libcalls (LLVM intrinsics) that LLVM by default would generate - and since SLEEF has highly optimal 8-wide pow, optimized for AVX and AVX2, we really want to use that. So we would not see 4/8 libcalls and instead see 1 call to something that lights up the ymm registers. I guess the problem then is that the default expectation is that pow would be

From: metafoo at gmail.com [mailto:metafoo at gmail.com] On Behalf Of Richard Smith Sent: Wednesday, September 12, 2012 2:51 PM To: Villmow, Micah Cc: Ouriel, Boaz; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] SPIR Portability Discussion On Wed, Sep 12, 2012 at 2:23 PM, Villmow, Micah <Micah.Villmow at amd.com<mailto:Micah.Villmow at amd.com>> wrote: From:

On Wed, Sep 12, 2012 at 2:23 PM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > ** ** > > ** ** > > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *Richard Smith > *Sent:* Wednesday, September 12, 2012 1:55 PM > *To:* Ouriel, Boaz > *Cc:* cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > *Subject:* Re:

Hi Boaz, I have a couple of specific questions: (a) You mention special calling conventions and adding them to LLVM. What are their semantics? And what is their purpose? (b) Why disallow type conversion for vector types? (ss. 3.3) Cheers, James On Tue, 2012-09-11 at 12:56 +0100, Ouriel, Boaz wrote: > Hi All, > > In continuation of the previous SPIR introduction email here is a link