similar to: [LLVMdev] RFC: Supporting different sized address space arithmetic

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

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

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,

On Fri, Aug 17, 2012 at 2:53 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Currently LLVM only supports address calculations for a single address > space(the default). This is problematic when the device pointer type is > 32/64bits, but there are small distinct memories that only have 16 bits of > addressing(think GPU's with small software controlled memory

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

> -----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 Fri, Aug 24, 2012 at 4:07 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > > >> -----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, Here is an updated patch. This is a lot smaller based on your feedback and still solves the same problem. For your comment on the IR changes, I'm reluctant to introduce changes there because really the backend is overriding the default behavior at a device specific level. The optimizations themselves can be dangerous, but still should produce correct results, this only allows the

> -----Original Message----- > From: Eli Friedman [mailto:eli.friedman at gmail.com] > Sent: Thursday, August 30, 2012 3:43 PM > To: Villmow, Micah > Cc: LLVM Developers Mail > Subject: Re: [LLVMdev] FW: RFC: Supporting different sized address space > arithmetic > > On Thu, Aug 30, 2012 at 3:27 PM, Villmow, Micah <Micah.Villmow at amd.com> > wrote: > >

On Thu, Aug 30, 2012 at 3:51 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > > >> -----Original Message----- >> From: Eli Friedman [mailto:eli.friedman at gmail.com] >> Sent: Thursday, August 30, 2012 3:43 PM >> To: Villmow, Micah >> Cc: LLVM Developers Mail >> Subject: Re: [LLVMdev] FW: RFC: Supporting different sized address space >>

On Thu, 30 Aug 2012 15:58:54 -0700 Eli Friedman <eli.friedman at gmail.com> wrote: > On Thu, Aug 30, 2012 at 3:51 PM, Villmow, Micah > <Micah.Villmow at amd.com> wrote: > > > > > >> -----Original Message----- > >> From: Eli Friedman [mailto:eli.friedman at gmail.com] > >> Sent: Thursday, August 30, 2012 3:43 PM > >> To: Villmow,

On Thu, Aug 30, 2012 at 3:27 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > > >> -----Original Message----- >> From: Eli Friedman [mailto:eli.friedman at gmail.com] >> Sent: Thursday, August 30, 2012 3:03 PM >> To: Villmow, Micah >> Cc: LLVM Developers Mail >> Subject: Re: [LLVMdev] FW: RFC: Supporting different sized address space >>

Doh! hit send too soon, patch attached. > -----Original Message----- > From: Villmow, Micah > Sent: Thursday, September 06, 2012 9:17 AM > To: 'Eli Friedman' > Cc: LLVM Developers Mail > Subject: RE: [LLVMdev] FW: RFC: Supporting different sized address space > arithmetic > > Eli, > Here is the first of many patches that adds support for specifying >

> -----Original Message----- > From: Eli Friedman [mailto:eli.friedman at gmail.com] > Sent: Thursday, August 30, 2012 3:03 PM > To: Villmow, Micah > Cc: LLVM Developers Mail > Subject: Re: [LLVMdev] FW: RFC: Supporting different sized address space > arithmetic > > On Thu, Aug 30, 2012 at 2:38 PM, Villmow, Micah <Micah.Villmow at amd.com> > wrote: > >

On Thu, Aug 30, 2012 at 2:38 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Eli, > Here is an updated patch. This is a lot smaller based on your feedback and still solves the same problem. The patch appears to be corrupt; can you regenerate it? > For your comment on the IR changes, I'm reluctant to introduce changes there because really the backend is overriding the

For my target, I handle incoming memory arguments by creating a store to memory (in LowerCall, [1]), then creating a fixed object on the stack and loading from it (in LowerFormalArguments[2]). This approach was based on MSP430. I now have the problem that the resulting loads in my output assembly are done assuming that the call stack looks something like: ------ MemArg ------ MemArg ------

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

Hi all! I'm getting starting with LLVM, and I'm creating a new cross-platform programming language LLVM-based with a Standard Library POSIX-based. The language has sintatic sugar of Object Pascal and Ruby. My doubt is if LLVM is compatible with AMD (e.g. Fusion), allowing so that my StdLib can be used to create Games, in future... Regards! -------------- next part -------------- An HTML

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

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