similar to: [LLVMdev] Backends supporting multiple LLVM revisions...

Currently top of tree is top of tree and no backwards compatibility, other than the C backend, is promised. I think that instead of asserting that you need to check in conditional compilation for a backend, perhaps, you would be open to other options to accomplish the same needs? My suggestion would be to check in or make some branches for the two older versions and then apply your patches on top

Eric, Once both AMD and Apple have advanced their respective internal LLVM versions past the point where AMDIL went in to LLVM TOT, then we can rip out all the conditional code and just have the one LLVM TOT. This is about managing the transition to that utopia… ;-) Until then, the choices really come down to having support for multiple LLVM versions in TOT, or having multiple backends.

On Fri, Dec 07, 2012 at 08:58:21PM +0000, Relph, Richard wrote: > Eric, > Once both AMD and Apple have advanced their respective internal LLVM versions past the point where AMDIL went in to LLVM TOT, then we can rip out all the conditional code and just have the one LLVM TOT. This is about managing the transition to that utopia… ;-) > Until then, the choices really come down to

I am proud to announce that AMD is Open Sourcing AMDIL Code Generator for LLVM 2.9. While this version is not for uptake into LLVM mainline, it does build and is compatible with LLVM 2.9. This is the first step of the process, so I know there will be issues that show up. In the next few months, we will be providing more unit tests and an LLVM 3.0 compatible version, and finally a TOT version for

Eric Christopher wrote: > On Wed, Jul 9, 2014 at 11:39 AM, Jonathan Roelofs > <jonathan at codesourcery.com> wrote: >> >> On 7/9/14, 12:33 PM, Eric Christopher wrote: >>> Any reason why you deleted code that isn't related? >>> >>> -eric >>> >>>> - enum SubArchType { >>>> - NoSubArch, >>>> -

We have a function that has 256 loads and 256 fmuladds. This block of operations is bounded at either end by an OpenCL barrier (an AMDIL fence instruction). The loads and multiply/adds are ordinarily interleaved... that is, the IR going in to code generation looks like: %39 = load float addrspace(3)* getelementptr inbounds ([16 x [17 x float]] addrspace(3)* @sgemm.b, i32 0, i32 0, i32 0), align

If the source being scanned has "llvm.AMDIL.barrier.global, it will match the first barrier test and return AMDIL_barrier, not AMDIL_barrier_global. On Nov 29, 2012, at 7:19 PM, Chris Lattner <clattner at apple.com> wrote: > Out of curiosity, what is wrong about that? It looks ok to me. > > -Chris > > On Nov 29, 2012, at 6:52 PM, "Relph, Richard"

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 Tom, I have a higher-level question regarding this back-end. If I have an LLVM IR module and run it through this back-end, it seems like the only output option is a binary format. Is this a device binary, or another intermediate format? If the input LLVM IR module was a compute kernel, how would I go about executing it on an AMD GPU? Can I use the APP SDK to load the binary, perhaps

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

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: Stellard, Thomas > Sent: Monday, May 28, 2012 9:07 AM > To: Justin Holewinski > Cc: Villmow, Micah; Tom Stellard; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] RFC: R600, a new backend for AMD GPUs > > On Mon, May 28, 2012 at 08:54:41AM -0700, Justin Holewinski wrote: > > On May 28, 2012 6:44 AM, "Tom Stellard"

Hello LLVMdev!! Yesterday I posted a patch request to the llvm-commits list requesting that someone could apply a patch to Triple.h and Triple.cpp for me. I didn't get any response so I wondered whether I should have posted to this list instead. My story is as follows: we are trying to get lldb/llvm support for CSRs range of Kalimba DSPs. Eventually we are planning to hire someone to

On 7/9/14, 12:33 PM, Eric Christopher wrote: > Any reason why you deleted code that isn't related? > > -eric > >> - enum SubArchType { >> - NoSubArch, >> - >> - ARMSubArch_v8, >> - ARMSubArch_v7, >> - ARMSubArch_v7em, >> - ARMSubArch_v7m, >> - ARMSubArch_v7s, >> - ARMSubArch_v6, >> -

On May 28, 2012 6:44 AM, "Tom Stellard" <thomas.stellard at amd.com> wrote: > > On Fri, May 25, 2012 at 02:37:26PM -0700, Justin Holewinski wrote: > > Hi Tom, > > > > I have a higher-level question regarding this back-end. If I have an LLVM > > IR module and run it through this back-end, it seems like the only output > > option is a binary

Here is a patch for LLVM 2.9 that adds AMDIL as a valid target triple to LLVM. I'll get an updated patch for LLVM TOT if this doesn't patch cleanly next. Micah -------------- next part -------------- A non-text attachment was scrubbed... Name: AMDIL_OpenSource.patch Type: application/octet-stream Size: 1488 bytes Desc: AMDIL_OpenSource.patch URL:

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

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

Is there a version of the AMDIL back-end that is compatible with LLVM 3.0/3.1? On Tue, May 29, 2012 at 8:33 AM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > > > > -----Original Message----- > > From: Stellard, Thomas > > Sent: Monday, May 28, 2012 9:07 AM > > To: Justin Holewinski > > Cc: Villmow, Micah; Tom Stellard; llvmdev at cs.uiuc.edu >

On Fri, May 25, 2012 at 02:37:26PM -0700, Justin Holewinski wrote: > Hi Tom, > > I have a higher-level question regarding this back-end. If I have an LLVM > IR module and run it through this back-end, it seems like the only output > option is a binary format. Is this a device binary, or another > intermediate format? > > If the input LLVM IR module was a compute kernel,