search for: hlls

On Jan 24, 2011, at 2:01 PM, David Given wrote: > I am interested in using LLVM to translate C and C++ into high-level > language code. (As an update to an earlier project of mine, Clue, which > used the Sparse compiler library to do this: it targets Lua, Javascript, > Perl 5, C, Java and Common Lisp, with a disturbing amount of success. > See http://cluecc.sourceforge.net for

On 25/01/11 00:17, David A. Greene wrote: [...] > The rewrite is happening. I've got the skeleton of the codegen done, > but I have to get it to build before I can check it in. After that, > everyone can start adding patterns. Is the new C backend 'register' based, that is, generating lots of little statements operating on lots of variables, rather than producing the huge

David Given <dg at cowlark.com> writes: > The obvious place to start on this is the C backend, except in these 2.8 > days the C backend is so hedged about with caveats I'm rather wary of > basing anything on it. I also recall seeing comments here that it's due > for a rewrite from scratch, and that various people were looking into > it. Can anyone go into more detail

On Jan 24, 2011, at 2:01 PM, David Given wrote: > I am interested in using LLVM to translate C and C++ into high-level > language code. (As an update to an earlier project of mine, Clue, which > used the Sparse compiler library to do this: it targets Lua, Javascript, > Perl 5, C, Java and Common Lisp, with a disturbing amount of success. > See http://cluecc.sourceforge.net for

I am interested in using LLVM to translate C and C++ into high-level language code. (As an update to an earlier project of mine, Clue, which used the Sparse compiler library to do this: it targets Lua, Javascript, Perl 5, C, Java and Common Lisp, with a disturbing amount of success. See http://cluecc.sourceforge.net for details.) The obvious place to start on this is the C backend, except in

...other languages. This means that (even if LLVM should be extended to support these operations eventually) you can always write them in assembly or whatever, then call them from LLVM. Note however that LLVM is _not_ a high-level language, and in fact we do not explicitly support _many_ features of HLLs directly in LLVM. We use a strategy of representing the key components of the high-level ideas using low-level primitives that can be used for a variety of purposes. If you describe what the time/sync operations are, maybe I can sketch out a suggested mapping for you. -Chris -- http://llvm.cs....

hi, In high level languge there are usually have time and sync instruction, to handle async and sync operation. I want to know how LLVM take an count of these. thanks yueqiang 2003/12/19 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20031218/07381085/attachment.html>

Now that the dust begins to settle... I'm wondering whether LLVM is for me. I'm working on something that can be used to create software for different environments: C/C++, JVM, CLR, Parrot, etc. I.e. one language for different environments, but not write once, run anywhere. Now what would be the role of LLVM in such an infrastructure? Just backend for C/C++ linkage, and I should go and

...hould be extended to support > > these operations eventually) you can always write them in assembly or > > whatever, then call them from LLVM. > > > > Note however that LLVM is _not_ a high-level language, and in fact we do > > not explicitly support _many_ features of HLLs directly in LLVM. We use a > > strategy of representing the key components of the high-level ideas using > > low-level primitives that can be used for a variety of purposes. If you > > describe what the time/sync operations are, maybe I can sketch out a > > suggested mappi...

On 5 October 2011 18:03, Justin Holewinski <justin.holewinski at gmail.com> wrote: >  So why must LLVM try to meet *both* goals?  Instead, different types of > front-ends can use custom intermediate representations that meet their > needs, and then lower to platform-specific LLVM IR before final code > emission.  I'm afraid that if LLVM gets into the game of trying to be the

...ycle counter on most modern processors (asm("rpcc %v0", foo) or __RPCC() compiler builtin on Alpha, e.g.); in the long term, a candidate for builtins I suspect. > Note however that LLVM is _not_ a high-level language, and in fact we do > not explicitly support _many_ features of HLLs directly in LLVM. We use a > strategy of representing the key components of the high-level ideas using > low-level primitives that can be used for a variety of purposes. If you > describe what the time/sync operations are, maybe I can sketch out a > suggested mapping for you. > W...

On Oct 4, 2011, at 4:42 PM, Renato Golin wrote: > On 5 October 2011 00:19, Chris Lattner <clattner at apple.com> wrote: >> 1. The native client folks trying to use LLVM IR as a portable representation that abstracts arbitrary C calling conventions. This doesn't work because the frontend has to know the C calling conventions of the target. > (...) >> 2. The OpenCL folks

On 5 October 2011 00:19, Chris Lattner <clattner at apple.com> wrote: > 1. The native client folks trying to use LLVM IR as a portable representation that abstracts arbitrary C calling conventions.  This doesn't work because the frontend has to know the C calling conventions of the target. (...) > 2. The OpenCL folks trying to turn LLVM into a portable abstraction language by

...t backend for C/C++ linkage, and I should go and look elsewhere for > JVM/CLR/whateverVM? > Should I look into LLVM subprojects? Which ones? It depends on what you want to do with the IR. If you want to create object files, LLVM is great. You just need to map the semantics of the various HLLs onto the LLVM IR language, as with any translator. For any kind of code-generator-ish thing, it's hard to beat LLVM IR, IMHO. If you want to JIT, then some of LLVM IR's limitations will impact the speed of code generation, as Dan outlined. If you want to do fancy transformations that u...

...ust backend for C/C++ linkage, and I should go and look elsewhere for > JVM/CLR/whateverVM? > Should I look into LLVM subprojects? Which ones? It depends on what you want to do with the IR. If you want to create object files, LLVM is great. You just need to map the semantics of the various HLLs onto the LLVM IR language, as with any translator. For any kind of code-generator-ish thing, it's hard to beat LLVM IR, IMHO. If you want to JIT, then some of LLVM IR's limitations will impact the speed of code generation, as Dan outlined. If you want to do fancy transformations that use...