[llvm-commits] PATCH: Add a few intrinsic definitions for r600

[Tom Stellard]

On Tue, Mar 20, 2012 at 03:16:53PM -0700, Jim Grosbach wrote:
> 
> On Mar 20, 2012, at 2:54 PM, Tom Stellard <thomas.stellard at amd.com> wrote:
> 
> > On Tue, Mar 20, 2012 at 02:21:17PM -0700, Bill Wendling wrote:
> >> On Mar 20, 2012, at 1:18 PM, Tom Stellard wrote:
> >> 
> >>> On Tue, Mar 20, 2012 at 12:00:07PM -0700, Bill Wendling wrote:
> >>>> On Mar 20, 2012, at 7:00 AM, Tom Stellard wrote:
> >>>> 
> >>>>> On Tue, Mar 20, 2012 at 02:27:21AM -0700, Bill Wendling wrote:
> >>>>>> Hi Tom,
> >>>>>> 
> >>>>>> Excuse my ignorance, but what is r600?
> >>>>>> 
> >>>>>> -bw
> >>>>> 
> >>>>> R600 is a target for the previous generation of AMD GPUs
> >>>>> (HD2XXX-HD6XXX).  There is an R600 LLVM backend being developed as part
> >>>>> of the Mesa project for compiling OpenCL kernels.  Latest code is here:
> >>>>> http://cgit.freedesktop.org/~tstellar/mesa/ in the clover-r600-master
> >>>>> branch.
> >>>>> 
> >>>> Thanks for the explanation. I guess my main concern is that we don't have an R600 back-end in the LLVM source tree. I'm hesitant to approve this because of that (others may disagree, though). Are there plans to add such a back-end to LLVM?
> >>>> 
> >>>> -bw
> >>>> 
> >>>> 
> >>> 
> >>> Hi,
> >>> 
> >>> I would really prefer to have the back-end live with the LLVM project,
> >>> it would make my life much easier.  However, without bug fix releases
> >>> of LLVM (e.g. 3.0.1), I don't think this is practical.
> >>> 
> >>> My main concern with this is that we'll want to release a stable version
> >>> of Mesa that uses the r600 back-end in LLVM 3.0 (or some other stable LLVM
> >>> version), but we'll find bugs in the 3.0 version of the back-end.
> >>> At this point we'll have two choices:
> >>> 
> >>> 1. Fix the bugs in the current SVN development branch of LLVM and release
> >>> a stable version of Mesa that depends on an unstable version of LLVM.
> >>> 
> >>> 2. Release a stable version of Mesa that depends on a stable version of
> >>> LLVM, but that has bugs we cannot fix.
> >>> 
> >> Another option is to qualify a specific "intermediate" version of LLVM for your project. I.e., create a branch from top-of-tree that is stable for you (passes your tests) and then add patches. You can do this for each stable release of Mesa. In fact, you could take the official release of LLVM and back port the patches yourself. It's not entirely dissimilar to what some other projects do. :-)
> > 
> > Can you point me to some projects that do this?  I would be interested
> > in seeing how they make it work.  We might be able to do this, though
> > I'm not sure how we could get distros to distribute our custom version
> > of LLVM along side the standard LLVM release.
> > 
> >> 
> >>> Neither of these situations are very desirable.
> >>> 
> >> The unfortunate truth is that no matter which LLVM you use -- official releases, a theoretical "dot" release, a patched version of an official release, or trunk -- there will always be bugs that haven't been found yet. It's the nature of complex pieces of software.
> > 
> > I understand this, but my point was that if we do find a bug, I'd like
> > to be able to fix it.
> > 
> >> 
> >>> The r600 back-end is very tightly integrated with the rest of the Mesa's
> >>> compute stack.  A single bug in the back-end could render the entire stack
> >>> unusable, which is why it is important to be able to release a stable
> >>> version of the back-end and a stable version of Mesa at the same time.
> >>> 
> >>> The bottom line is: If we make a stable release of Mesa we need to be
> >>> able to fix all bugs that turn up, and I don't think this is possible
> >>> with the r600 back-end in the LLVM source tree.
> >>> 
> >>> Is there any possibility that the LLVM project would start doing bug fix
> >>> releases?  Has this ever been discussed in the past?
> >>> 
> >> As Anton mentioned, it takes resources to do a dot release -- both human and machine time. We just don't have enough of either to do this. However, we do release official versions of LLVM on a fairly regular basis; typically every 6 months.
> > 
> > Makes sense.
> > 
> >> 
> >> -bw
> >> 
> >> 
> > 
> > Could I get either an ACK or NAK on this patch (and maybe this patch
> > too: http://permalink.gmane.org/gmane.comp.compilers.clang.scm/48532),
> > so I can start planning what to do next.
> > 
> 
> What's the benefit of adding the intrinsics to trunk llvm if the backend itself is going to remain separate?
>

Those intrinsics definitions were needed by Clang, so it would know what
to do with r600 builtins.  Though, it's not important any more, because
I think I'm going to try get the r600 backend into the LLVM tree.

-Tom

> > Thanks,
> > Tom
> > 
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 
>