[LLVMdev] C Backend Ressurected

[Isaac Dupree]

I would like to ship an application that can compute on multiple brands
of modern GPU.  I would like to write my GPU code in a slightly higher
level language than OpenCL's C variant -- for example, C++ templates
would be useful to have.  One way might be compiling some higher level
language to OpenCL that I ship.  Can you suggest better ways to do this?

Best,
-Isaac

On 09/03/2014 04:10 PM, Eric Christopher wrote:
> I can't see why you'd want to do this, no.
> 
> -eric
> 
> 
> On Tue, Aug 19, 2014 at 8:02 PM, Isaac Dupree
> <ml at isaac.cedarswampstudios.org <mailto:ml at isaac.cedarswampstudios.org>>
> wrote:
> 
>     Is the C backend at all suitable to be adapted to emit OpenCL code?  Or
>     do the target-dependence, and/or things that C can do but OpenCL can't,
>     make that hopeless?
>     -Isaac
> 
>     On 08/19/2014 03:08 PM, Carback, Richard T., III wrote:
>     > It provides a useful starting point, but I agree with Jim that it
>     is not
>     > a complete solution and requires rework of the results in a lot
>     cases. I
>     > think we could improve it further to address these issues but that
>     work
>     > is nontrivial.
>     >
>     >
>     >
>     > If you are deciding between a quick and dirty implementation of a
>     custom
>     > backend vs. the C backend, then the C backend is sometimes
>     preferable in
>     > my experience although it depends on the complexity of the code
>     you are
>     > trying to run and how often you need to change it.
>     >
>     >
>     >
>     > *From:*llvmdev-bounces at cs.uiuc.edu
>     <mailto:llvmdev-bounces at cs.uiuc.edu>
>     [mailto:llvmdev-bounces at cs.uiuc.edu
>     <mailto:llvmdev-bounces at cs.uiuc.edu>]
>     > *On Behalf Of *Jim Grosbach
>     > *Sent:* Tuesday, August 19, 2014 2:12 PM
>     > *To:* Bruce Hoult
>     > *Cc:* llvmdev at cs.uiuc.edu <mailto:llvmdev at cs.uiuc.edu>
>     > *Subject:* Re: [LLVMdev] C Backend Ressurected
>     >
>     >
>     >
>     > This is part of the problem with the C backend. This is very much not
>     > what it’s useful for, yet it very much looks like it is. The LLVM
>     IR is
>     > target dependent, including things like structure layout, pointer
>     size,
>     > and other ABI issues. Even with a resurrected C backend, you can’t use
>     > it as a substitute for real target support.
>     >
>     >
>     >
>     > -Jim
>     >
>     >
>     >
>     >     On Aug 18, 2014, at 7:02 PM, Bruce Hoult <bruce at hoult.org
>     <mailto:bruce at hoult.org>
>     >     <mailto:bruce at hoult.org <mailto:bruce at hoult.org>>> wrote:
>     >
>     >
>     >
>     >     I don't know how good it is, but the applications seem
>     obvious. e.g.
>     >     compiling programs in any of a number of original formats to run
>     >     natively on CPUs that have a working simple C compiler (maybe only
>     >     K&R or C89) but don't have an LLVM back end.
>     >
>     >
>     >
>     >     The source program could be in modern C, C++, or any other high
>     >     level language or assembly language with a translator to LLVM.
>     >
>     >
>     >
>     >     On Tue, Aug 19, 2014 at 1:40 PM, Jun Koi <junkoi2004 at gmail.com
>     <mailto:junkoi2004 at gmail.com>
>     >     <mailto:junkoi2004 at gmail.com <mailto:junkoi2004 at gmail.com>>>
>     wrote:
>     >
>     >
>     >
>     >
>     >
>     >     On Mon, Aug 18, 2014 at 9:18 PM, Carback, Richard T., III
>     >     <rcarback at draper.com <mailto:rcarback at draper.com>
>     <mailto:rcarback at draper.com <mailto:rcarback at draper.com>>> wrote:
>     >
>     >         Hi All,
>     >
>     >
>     >
>     >         2 of my summer interns (Aimee Dipietro and Greg Simpson) used
>     >         their time over the summer to resurrect the LLVM C Backend:
>     >
>     >
>     >
>     >         https://github.com/draperlaboratory/llvm-cbe
>     >
>     >
>     >
>     >         Improvements include recovery of simple for/while loops
>     (instead
>     >         of goto), better variable naming, inline asm support, and
>     making
>     >         it work on a more recent version of llvm. I believe they used
>     >         the repository here as a starting point:
>     >
>     >
>     >
>     >         https://github.com/glycerine/llvm/tree/cbe_revival
>     >
>     >
>     >
>     >         Feedback is welcomed. I would like to see this feature put
>     back
>     >         into LLVM, and any help on how to make that happen would be
>     >         appreciated.
>     >
>     >
>     >
>     >     would you mind explaining what this backend is for, and its
>     >     applications?
>     >
>     >     i guess it is to get the C code at the output of the backend, but
>     >     dont get why we need it.
>     >
>     >     thanks,
>     >
>     >     Jun
>     >
>     >
>     >     _______________________________________________
>     >     LLVM Developers mailing list
>     >     LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>     <mailto:LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>>
>     >      http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
>     >     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>     >
>     >
>     >
>     >     _______________________________________________
>     >     LLVM Developers mailing list
>     >     LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>     <mailto:LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>>
>     >             http://llvm.cs.uiuc.edu
>     >     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>     >
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > LLVM Developers mailing list
>     > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>       
>      http://llvm.cs.uiuc.edu
>     > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>     >
> 
>     _______________________________________________
>     LLVM Developers mailing list
>     LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>       
>      http://llvm.cs.uiuc.edu
>     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
>