similar to: [LLVMdev] Immediate instructions / register allocator

On Mon, Oct 22, 2012 at 3:38 AM, Jonas Paulsson <jonas.paulsson at ericsson.com> wrote: > Hi, > > > > I tried transforming code that loads an immediate into a virtual register, > and then uses that virtual register in various ways, into code that uses > immediate operands instead. I suspect a concrete example might be helpful in demonstrating the specific issue. >

Khronos has announced a Request For Quotations for a WebCL Kernel Validator. The Validator will enforce compliance of WebCL kernels with the defined WebCL language restrictions, and prevent out of bounds memory accesses. The WebCL kernel Validator will enforce out of bounds memory protections, and will perform syntactic validation of WebCL kernels. The WebCL Validator RFQ can be accessed from:

Dear R community, I am using a dataset and would like to define new variables using a R variable: e.g. for (i in 1:10){ dataset$i<-something } But this is not the right way, I get only one variable in "dataset"... How can I change this? Thank you! Georg. ************************ Georg Ehret Johns Hopkins Baltimore, MD [[alternative HTML version deleted]]

Hi All, The description of ScheduleDAGMILive [1] says: ScheduleDAGMILive is an implementation of ScheduleDAGInstrs that schedules machine instructions while updating LiveIntervals and tracking regpressure. Does the live interval and register pressure part of ScheduleDAGMILive mean the subclass of ScheduleDAGMILive is a pre-RA scheduler? I assume the post-RA scheduler no need to take

Hi All, In continuation of the previous SPIR introduction email here is a link to the specification: http://www.khronos.org/registry/cl/specs/spir_spec-1.0-provisional.pdf The first topic which we would like to discuss is "SPIR portability". I will send soon an additional mail which will help in leading the discussion on this topic. Thanks and happy reading, Boaz -----Original

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

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

Greetings All, I am sending this mail on behalf of the OpenCL Khronos members. **** 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 LLVM mailing list. Khronos members

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

I see that there are several options to influence instruction scheduling, but there doesn't seem to be a lot of information about what they do, for example: -misched-topdown -misched-bottomup The description in MachineScheduler.cpp says: "Force top-down list scheduling" and "Force bottom-up list scheduling" Which isn't too helpful - where might I want to use these?

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

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

Hi, Indeed, the complex add is more expensive on all Cortex cores I know of. However there is an important point here that the code sequence we generate requires two registers live instead of one. In high regpressure loops, were probably losing performance. James On Wed, 11 Nov 2015 at 21:09, Tim Northover via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 11 November 2015 at

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

On 07/31/2017 02:30 PM, Nicholas Wilson via llvm-dev wrote: > >> On 31 Jul 2017, at 3:23 pm, Neil Henning <ll... at duskborn.com> wrote: > > Moving forward, other than securing the triples spirv32, spirv64, and spirvlogical from LLVM, how can we go about coordinating efforts? I feel that having one backend is a better use of everybody’s time than having three. If we

On Wed, May 13, 2015 at 6:11 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > On 13 May 2015, at 13:56, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > > > > Khronos Group SPIR WG is working on a bi-way converter between LLVM > bitcode and SPIR-V ( > https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf ) binary and > is willing to upstream

Hi Andrew, Shuxin, Thanks for the explanation about 'Reassociate'. The problem is indeed that one of the variables, becomes loop invariant after some of the loop transformations. > -----Original Message----- > From: Andrew Trick [mailto:atrick at apple.com] [...] > Right. Reassociate ranks expressions by their order in the IR, so shouldn't > make matters worse, but it