similar to: [LLVMdev] Python Backend

Hi, I have a version of the old CBackend which is working with the current trunk. I am in the progress of rewriting it into a new version but that project is not going as fast as I would hope as I have been distracted by other tasks with higher priority lately. Anyway, for those interested, I can provide patches, optionally separated into several parts (core, testing, misc). I am afraid that

I'm very interested in this patch. Could you, Roel, upload it somewhere or maybe put your code to github or something simmilar? Additional - you're fixing it - could you please provide a little more information - what should I read to get more informations about writing not hardware but software backend in LLVM? (Of course the code analysis is one way, but maybe there is other also).

> ---------------------------------------------------------------------------------- > 2) > Maybe this question I will answer myself by analising some examples you'll > provide as answer to the first question, but maybe it will worth asking it > now. > So I want to know when to generate a class in Python. So far I know, that in > LLVM there are no classes, only functions,

I will take a look into NVPTX. I don't want to deconstruct C++ classes to generate Python code - I want to generate Python backend :) Its purpose is to be able to generate Python code from LLVM IR code (not C++ code! - C++ code is needed for me only to get a sample IR code). I want to write my custom compiler in the future and I want to be able to output Python code from it (of course not

Dear LLVM experts! we would like to use BeignetBackend as and LLVM Target It shown in teh Beignet code there is a note "Well, the complete code base is somehow a compiler backend for LLVM. Here, we really speak about the final code generation passes that you may find in `src/backend`." http://www.freedesktop.org/wiki/Software/Beignet/Backend/compiler_backe nd/ But Beignet does not

> 2.i want to write such a test:translate a *.ll(i.e:hello.ll) file to a > *.c file(i.e:hello.c) with llc,then verify if the .c file contian a > certain string(i.e:"abc:). so: It seems you want to test LLVM C backend, go looking for llvm-3.0.src/test/CodeGen/CBackend/* (C backend had been removed from LLVM 3.1). HTH, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute

> I'm periodically updating my local version of the LLVM, and, when I did it > today, I couldn't use the llc with -march=c. Looking for the CBackend files, > I realized that they were removed from the LLVM folder. I actually don't > remember reading about a drop of this capability in any of the devlist > messages, so I was wondering if this removal could be only

Dear Jim and Owen, Thanks for replies, I only kindly suggest some discussion on the maillist in such cases. Just in general, nasty precedents sometimes happen, for example on IRC I've recently seen some commits to Objective C were requested to be reverted, because they were commited without any discussion. Here things are certainly not that hard, but the point is the same: it is always nice

I am getting problems with 'make check' on Linux x86. Several instances of 'couldn't execute "-emit-llvm": no such file or directory' :- FAIL: /usr/src/llvm/test/CodeGen/CBackend/2007-01-06-Signless.c Failed with posix(ENOENT,no such file or directory) at line 1 while running: -emit-llvm -S /usr/src/llvm/test/CodeGen/CBackend/2007-01-06-Signless.c -o -

Hi I currently would like to find out the signedness of a instruction. But looking at the CBackend, it looks as if it is not that simple? So i have two questions: Is there an easier way than guessing as it is done in the CBackend? Is there a reason for that signedness is not part of the instruction type? Best regards ST

Dear all, I've also noticed C backend was removed a little bit... silently. In the end of March I only got open bugs closed by Benjamin Kramer in bugzilla, but they sounded like "decision is made". So the question is: it such silent removal a normal practice? In times of 3.0 release there were long discussions on what to drop and what to preserve, e.g. sparc backend, if I remember

Hi Dmitry, Where were you expecting notice to have been given? If I recall correctly, the obsolescence of the C backend was mentioned many times on this mailing list, and as Owen notes, in the release notes since 2.8. I'm not trying to be snarky. You were obviously genuinely surprised by its removal, and that makes me wonder if where the core open source devs are expecting people to look for

On Tue, Nov 20, 2012 at 4:10 PM, Wojciech Daniło <wojtek.danilo.ml at gmail.com> wrote: > I will take a look into NVPTX. > > I don't want to deconstruct C++ classes to generate Python code - I want to > generate Python backend :) > Its purpose is to be able to generate Python code from LLVM IR code (not C++ > code! - C++ code is needed for me only to get a sample IR

Hi everyone, I'm using the LLVM in a project, and I'm specially interested in using its optimizer. After apply the optimizations, I needed to create a C/C++ source code equivalent to the original one. I'm periodically updating my local version of the LLVM, and, when I did it today, I couldn't use the llc with -march=c. Looking for the CBackend files, I realized that they were

On Fri, 2005-04-22 at 09:52 -0600, Al Stone wrote: > On Fri, 2005-04-22 at 10:18 -0500, Chris Lattner wrote: > > Would passing one option, "--enable-arch=host", be ok? > > If what you mean is that "--enable-arch=host" would build only the > host target, that could work. "--enable-arch=host-only" or something > _might_ be clearer. So let me

NetBSD does not have alloca.h, so CBackend.cpp need to handle NetBSD in the same way as FreeBSD and OpenBSD, as in the attached patch. /Krister -------------- next part -------------- Index: CBackend.cpp =================================================================== --- CBackend.cpp (revision 45865) +++ CBackend.cpp (working copy) @@ -1323,7 +1323,7 @@ static void

> Several instances of 'couldn't execute "-emit-llvm": no such file or directory' :- > > FAIL: /usr/src/llvm/test/CodeGen/CBackend/2007-01-06-Signless.c > Failed with posix(ENOENT,no such file or directory) at line 1 > while running: -emit-llvm -S /usr/src/llvm/test/CodeGen/CBackend/2007-01-06-Signless.c -o - | llvm-as | llc -march=c | grep

>> Several instances of 'couldn't execute "-emit-llvm": no such file or >> directory' :- >> >> FAIL: /usr/src/llvm/test/CodeGen/CBackend/2007-01-06-Signless.c >> Failed with posix(ENOENT,no such file or directory) at line 1 >> while running: -emit-llvm -S >> /usr/src/llvm/test/CodeGen/CBackend/2007-01-06-Signless.c -o - |

On Tue, Jun 3, 2008 at 2:42 AM, ST <st at iss.tu-darmstadt.de> wrote: > Hi > > I currently would like to find out the signedness of a instruction. But > looking at the CBackend, it looks as if it is not that simple? So i have two > questions: > Is there an easier way than guessing as it is done in the CBackend? > Is there a reason for that signedness is not part of the

Hi, I want to invoke the AddReadAttrs pass with my software backend (derived from TargetMachine like CBackend). CBackend uses addPassesToEmitWholeFile-method for invoking several passes. I tried to use the same method, but it failed on runtime. Running llc with my backend produces (mac os x 10.5 and llvm 2.4): dyld: lazy symbol binding failed: Symbol not found: