[Beignet] [PATCH] Compile against upstream LLVM 3.3

[Zhigang Gong]

> -----Original Message-----
> From:
> beignet-bounces+zhigang.gong=linux.intel.com at lists.freedesktop.org
> [mailto:beignet-bounces+zhigang.gong=linux.intel.com at lists.freedesktop.
> org] On Behalf Of Steven Newbury
> Sent: Monday, April 22, 2013 1:52 PM
> To: Boqun Feng
> Cc: beignet at lists.freedesktop.org
> Subject: Re: [Beignet] [PATCH] Compile against upstream LLVM 3.3
> 
> On Mon, 2013-04-22 at 10:01 +0800, Boqun Feng wrote:
> > hi Steven, we also have tried to build with llvm3.3 several months
> > before
> > 0.1 release, but problem is that PTX changed after llvm3.3, PTX is
> > some IR of cl code, it seems there will be a little more work to do
> > with that, we need to modify our backend to work with new PTX, or
> > maybe, we can translate cl code directly to GEN IR.
> >
> >
> I did have this working to some extent back at the beginning of March, I
> can try to bisect the change and work out what needs to be done although
> the error seems to me a little odd for an IR incompatibility,  it fully
> appears that none of the CL built-in types are defined!
> 
> Maybe, there's also a problem with PTX changes, but I'm pretty sure I'm
> hitting something else, which could entirely be a local Clang
> installation problem.  Maybe it can't find the headers?  I'd expect an
> error message though!  I'm using Gentoo, and I recently switched to
> SYMLINK_LIB=n (Gentoo multilib traditionally uses lib32 for x86 and
> lib64 symlinked to lib for amd64, SYMLINK_LIB=n results in lib for x86
> and lib64 for amd64 as has become the standard) so my local Clang ebuild
> tries to take this into account.
> 
> Given that it's probably going to be some work to get it working again
> maybe it would be a good opportunity to spend the effort porting the
> code to Gallium/Clover rather than chasing upstream Clang/LLVM
> breakages?
> >
> >
> > On Sun, Apr 21, 2013 at 11:51 PM, Steven Newbury
> > <steve at snewbury.org.uk> wrote:
> >         On Sun, 2013-04-21 at 12:27 +0100, Steven Newbury wrote:
> >         > "LLVM_33" isn't exactly future-proof, but this is enough to
> >         build
> >         > against LLVM trunk.  Currently, it's not working at run-time
> >         possibly
> >         > due to changes to the clang frontend arguments/backend
> >         selection?  Or
> >         > perhaps it's my clang build..?  It was working for me
> >         against an earlier
> >         > clang/llvm checkout.
> >         >
> >
> >         I'm pretty convinced it's something weird with my local
> >         clang/llvm
> >         install.
> >
> >         Errors all look something like this:
> >
> >         compiler_clod:
> >         /tmp/fileA0M1gZ.cl:198:38: error: expected identifier or '('
> >         typedef __texture struct _image2d_t* image2d_t;
[Gong, Zhigang] 

My best guessing is that the latest llvm 3.3 svn introduces the "image2d_t"
and some related keywords in FE
which is incompatible with Beignet's current implementation. One possible
workaround is to redefine image2d_t
to another name such as the following :

#define image2d_t  beignet_image2d_t

And put this line at the beginning of the ocl_stdlib.h. It should work. 


- Zhigang Gong