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> 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] > > *On Behalf Of *Jim Grosbach > > *Sent:* Tuesday, August 19, 2014 2:12 PM > > *To:* Bruce Hoult > > *Cc:* 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>> 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>> wrote: > > > > > > > > > > > > On Mon, Aug 18, 2014 at 9:18 PM, Carback, Richard T., III > > <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> > > 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> > > http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > > > > > > > _______________________________________________ > > LLVM Developers mailing list > > 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 http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140903/28b6c71b/attachment.html>
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 > >
On Sep 3, 2014, at 7:10 PM, Isaac Dupree <ml at isaac.cedarswampstudios.org> wrote:> 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, > -IsaacThis was the intended use case for SPIR> > 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 >> >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev