[Libclc-dev] architecture-specific builtins and OpenCL

Tom Stellard tom at stellard.net
Tue Nov 11 10:09:21 PST 2014


On Tue, Nov 11, 2014 at 01:01:16PM -0500, Richard Gorton wrote:
> I originally posted this to llvmdev,but it strikes me that this might be a better place to make the query.
> 
> 
> > I'm trying to ascertain whether or not it is possible to use architecture-specific builtins (LLVM3.4.2) in OpenCL:
> > 
> > This compiles cleanly for my target when it has a .c extension:
> > 
> > void fred(unsigned long* in, unsigned long* where)
> > {
> >    *where = __builtin_coge_reverse(*in);
> > }
> > 
> > But this variant crashes very early when it is a .cl file:
> > void kernel fred(unsigned long *in, unsigned long* where)
> > {

I just realized you are passing private pointers to your kernel.  This is
not allowed in OpenCL.  Does it work if you drop the kernel attribute?

-Tom

> >    *where = __builtin_coge_reverse(*in);
> > }
> > 
> > 
> > 
> > I'm not even sure how to go about determining the source of problem - it crashes before generating any IR (-mllvm -print-after-all)
> > 
> > clang: /localspace/rcgorton/svn/Compiler/trunk/LLVM3_4/llvm-3.4.2.src/lib/IR/Instructions.cpp:2352: static llvm::CastInst* llvm::CastInst::Create(llvm::Instruction::CastOps, llvm::Value*, llvm::Type*, const llvm::Twine&, llvm::Instruction*): Assertion `castIsValid(op, S, Ty) && "Invalid cast!"' failed.
> > 
> > Is there a document somewhere which describes how to use various front-end-dumping switches?  Is there a better way to attack this?
> > 
> > Thanks in advance,
> > 
> > 	Richard
> > 	rcgorton at cog-e.com
> 
> _______________________________________________
> Libclc-dev mailing list
> Libclc-dev at pcc.me.uk
> http://www.pcc.me.uk/cgi-bin/mailman/listinfo/libclc-dev




More information about the Libclc-dev mailing list