similar to: [LLVMdev] Live-in to argument mapping

One of the requirements for the backend that I am targeting is certain meta-data needs to be returned to the runtime. This includes the mapping between parameters and the locations this data is expected to be stored at. This is mainly because there are multiple address spaces and each one is mapped differently but all are assigned registers from the same register class. So this mapping needs to be

On Tue, Dec 13, 2011 at 12:54 PM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > ** ** > > ** ** > > *From:* Justin Holewinski [mailto:justin.holewinski at gmail.com] > *Sent:* Tuesday, December 13, 2011 9:48 AM > *To:* Villmow, Micah > *Cc:* LLVM Developers Mailing List > *Subject:* Re: [LLVMdev] Changes to the PTX calling conventions**** > > ** ** >

From: Justin Holewinski [mailto:justin.holewinski at gmail.com] Sent: Tuesday, December 13, 2011 9:48 AM To: Villmow, Micah Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] Changes to the PTX calling conventions On Tue, Dec 13, 2011 at 11:25 AM, Villmow, Micah <Micah.Villmow at amd.com<mailto:Micah.Villmow at amd.com>> wrote: Currently, PTX has its own calling conventions where

On Sep 25, 2008, at 10:49 AM, Villmow, Micah wrote: > I am having trouble trying to figure out two pieces of information > from attempting to map arguments to registers. > How do I determine, based on the argument name, which register the > value is supposed to be assigned to? > I can hard-coded it currently and it will be correct 100% of the > time with the current set of

On Tue, Dec 13, 2011 at 11:25 AM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > Currently, PTX has its own calling conventions where they are split into > kernel/device. **** > > The AMDIL backend requires very similar calling conventions and I was > wondering if **** > > we could change the calling conventions from PTX_* to something more > generic?**** >

From: Justin Holewinski [mailto:justin.holewinski at gmail.com] Sent: Tuesday, December 13, 2011 10:50 AM To: Villmow, Micah Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] Changes to the PTX calling conventions On Tue, Dec 13, 2011 at 12:54 PM, Villmow, Micah <Micah.Villmow at amd.com<mailto:Micah.Villmow at amd.com>> wrote: From: Justin Holewinski [mailto:justin.holewinski

I am having trouble trying to figure out two pieces of information from attempting to map arguments to registers. How do I determine, based on the argument name, which register the value is supposed to be assigned to? I can hard-coded it currently and it will be correct 100% of the time with the current set of assumptions, but I would rather determine it dynamically so that I can change my

On Tue, Dec 13, 2011 at 3:37 PM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > ** ** > > *From:* Justin Holewinski [mailto:justin.holewinski at gmail.com] > *Sent:* Tuesday, December 13, 2011 10:50 AM > > *To:* Villmow, Micah > *Cc:* LLVM Developers Mailing List > *Subject:* Re: [LLVMdev] Changes to the PTX calling conventions**** > > ** ** > > On

On Mon, 27 Aug 2012 15:25:50 +0000 "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > Most likely this code was added before getSExtOrTruncate was added, > but not 100% sure. It seems to assume that no pointer can be more > than 64bits in size. Does LLVM generally support pointers of greater than 64 bits? -Hal > > > -----Original Message----- > >

Currently, PTX has its own calling conventions where they are split into kernel/device. The AMDIL backend requires very similar calling conventions and I was wondering if we could change the calling conventions from PTX_* to something more generic? Maybe just Kernel/Device? Or would it be preferable to add a new calling convention that is unique for each target, even though it duplicates

Micah, There are a number of variable names in this patch that don't follow the naming convention (which specifies that they should start with an uppercase letter). > if (PtrBits < 64) > - OffsVal = DAG.getNode(ISD::TRUNCATE, getCurDebugLoc(), > - TLI.getPointerTy(), > + OffsVal = DAG.getNode(ISD::TRUNCATE,

Most likely this code was added before getSExtOrTruncate was added, but not 100% sure. It seems to assume that no pointer can be more than 64bits in size. > -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: Friday, August 24, 2012 4:27 PM > To: Villmow, Micah > Cc: LLVM Developers Mail > Subject: Re: [LLVMdev] FW: RFC: Supporting different sized

Hi, as you come to speak of it, i have implemented an OpenCL-Backend for LLVM as part of my bachelor thesis (and for GLSlang as well, see http://www.cdl.uni-saarland.de/publications/theses/moll_bsc.pdf ). However, the code is currently unreleased. But that could be arranged, if you are interested in using it. Regards, Simon Am Freitag, den 26.08.2011, 20:11 -0500 schrieb llvmdev-request at

Michele, The information you are trying to gather is fundamentally static information, and as such can be implicit. It doesn't matter what OpenCL program you are trying to compile, the address space information for each backend doesn't change. So there are multiple ways to do this without requiring a new interface into LLVM and further linking the backends and the frontend. 1) Utilize

> -----Original Message----- > From: Michele Scandale [mailto:michele.scandale at gmail.com] > Sent: Friday, August 09, 2013 11:41 PM > To: Micah Villmow > Cc: James Courtier-Dutton; LLVM Developers Mailing List > Subject: Re: [LLVMdev] Address space extension > > Hi Micah, > > On 08/10/2013 06:01 AM, Micah Villmow wrote: > > Michele, > > Why can not

> -----Original Message----- > From: Villmow, Micah > Sent: Friday, August 24, 2012 2:56 PM > To: 'Eli Friedman' > Cc: LLVM Developers Mailing List > Subject: RE: [LLVMdev] RFC: Supporting different sized address space > arithmetic > > Eli, > There is a patch that implements the beginning what I think is the > correct approach to support the backend

On Dec 12, 2011, at 9:09 AM, Villmow, Micah wrote: LLVM-IR that isn’t generated from AMD’s OpenCL frontend does not produce any AMDIL. Is this because of the way metadata is handled? If so, will that technique be documented? Or can it be reasonably inferred from the source code? Thanks, Marcus -------------- next part -------------- An HTML attachment was scrubbed... URL:

> -----Original Message----- > From: Eli Friedman [mailto:eli.friedman at gmail.com] > Sent: Friday, August 17, 2012 3:16 PM > To: Villmow, Micah > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] RFC: Supporting different sized address space > arithmetic > > On Fri, Aug 17, 2012 at 2:53 PM, Villmow, Micah <Micah.Villmow at amd.com> > wrote: > >

On Thu, Oct 8, 2009 at 11:28 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > > >> -----Original Message----- >> From: Jeffrey Yasskin [mailto:jyasskin at google.com] >> Sent: Thursday, October 08, 2009 11:09 AM >> To: Villmow, Micah >> Cc: LLVM Developers Mailing List >> Subject: Re: [LLVMdev] Instructions that cannot be duplicated >>

Hi Micah, On 08/10/2013 06:01 AM, Micah Villmow wrote: > Michele, > Why can not the target triple implicitly encode the address space mapping? I would not expect address spaces to map correctly if I compile OpenCL code on an AMD device and then compile the IR on an NVidia device. Even an AMD device targeted from OpenCL could have a different mapping than the same AMD device targeted from