Displaying 20 results from an estimated 900 matches similar to: "[LLVMdev] Backend for the ZPU - a stack based / zero operand CPU"
2008 Jun 20
1
[LLVMdev] Backend for the ZPU - a stack based / zero operand CPU
> On Jun 19, 2008, at 2:30 PM, ?yvind Harboe wrote:
>> My llvm.org knowledge is ... shallow ... but I'm hoping that
>> someone would find the time & pity to answer my questions:
>>
>> Q: Is a stack based / zero operand CPU and llvm a good match? (GCC
>> wasn't)
>
> I'm not really sure, I'm not too familiar with these architectures.
>
2008 Jun 19
2
[LLVMdev] Backend for the ZPU - a stack based / zero operand CPU
Hi all,
Zylin has implemented the world smallest 32 bit CPU with
a GCC backend. (I shall stand corrected if anyone claims
& proves otherwise :-)
Implementing a GCC backend for a zero operand/stack based
architecture proved pretty tricky, but I'm quite pleased with
the resulting code. I did make alterations to the architecture
to make it fit GCC without sacrificing CPU size.
I have been
2008 Jun 23
0
[LLVMdev] Backend for the ZPU - a stack based / zero operand CPU
> We mean ZPU looks like x86 fp stack. We handle it by register
> allocating it like a normal register based cpu than add a x87
> stackifer pass to convert it to stack operations.
Thanks!
> You do not have to. Take a look at PPC and ARM branch fix up passes.
> llvm backends compute exact length of instructions so it can determine
> when it is necessary to convert a conditional
2010 Nov 18
0
[LLVMdev] Writing a backend for the ZPU
Hi,
I'm trying to have another stab at writing an LLVM ZPU backend.
Any pointers or encouragement would be greatly appreciated.
So far I've been wandering around the LLVM trying to read up and
I've hacked together something that builds just to experiment and
get a feel for the build system. I was able to write a backend
for GCC which has been in use for years now, but I can't
2008 Jun 24
1
[LLVMdev] jit DLLs
> ?yvind Harboe wrote:
>> Are JIT DLLs supported?
>>
>> The idea is to use llvm to put performance sensitive code into
>> a DLL that a Windows app can then use.
>>
>> This would build the performance sensitive code on the target
>> machine making it possible to exploit CPU specific x86
>> vector instructions.
>>
>> The code that calls
2008 Jun 24
4
[LLVMdev] jit DLLs
Are JIT DLLs supported?
The idea is to use llvm to put performance sensitive code into
a DLL that a Windows app can then use.
This would build the performance sensitive code on the target
machine making it possible to exploit CPU specific x86
vector instructions.
The code that calls fn's in the DLL should, ideally, be unaware
that a llvm JIT is being used.
--
Øyvind Harboe
2010 Nov 19
0
[LLVMdev] Fw: Writing a backend for the ZPU
Whoops! Forgot to CC: the list!
----- Forwarded Message -----
> From:Samuel Crow <samuraileumas at yahoo.com>
> To:Øyvind Harboe <oyvind.harboe at zylin.com>
> Cc:
> Sent:Thursday, November 18, 2010 7:22:39 PM
> Subject:Re: [LLVMdev] Writing a backend for the ZPU
>
>
> Hello,
Some
> thoughts/problems:
- In GCC I created
> registers which were
2011 Jun 30
2
[LLVMdev] GCC 4.1 ABI and clang
On Thu, Jun 30, 2011 at 3:43 PM, Duncan Sands <baldrick at free.fr> wrote:
> On 30/06/11 15:13, Øyvind Harboe wrote:
>>> Sorry, I meant from which version of clang? I'm using Ubuntu 10 and
>>> I was wondering if clang/llvm 2.8 would do it.
>>
>> Perhaps I better try the latest, got an error when I tried 2.8:
>
> C++ support in clang 2.8 was poor.
2011 Jun 30
0
[LLVMdev] GCC 4.1 ABI and clang
On Thu, Jun 30, 2011 at 2:03 PM, Duncan Sands <baldrick at free.fr> wrote:
> Hi Øyvind,
>
>> I'm trying to find some written evidence to present to the powers
>> that be that clang/llvm is ABI compatible with GCC 4.1 linux
>> 64 bit.
>
> both clang and gcc-4.1 are supposed to conform to the platform ABI (if they
> don't then that is a bug), and thus
2011 Jul 03
3
[LLVMdev] Deleting unused C++ code
Can llvm generate warnings for unused C++ code using global
analysis?
If I could use llvm to figure out what code I can delete in a 20
year old app with millions of lines of code, this alone would defend
spending time on making the app build with llvm, even if we don't
actually run the code generated...
--
Øyvind Harboe - Can Zylin Consulting help on your project?
US toll free
2011 Jun 30
2
[LLVMdev] iosfwd problems
I've tried llvm 2.8 and 2.9, but they both have problems with
#include <iosfwd>.
Any pointers to what this might be?
/usr/include/c++/4.5/iosfwd:39:10: fatal error: 'bits/c++config.h'
file not found
#include <bits/c++config.h>
--
Øyvind Harboe - Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/
2011 Jun 30
2
[LLVMdev] GCC 4.1 ABI and clang
> Sorry, I meant from which version of clang? I'm using Ubuntu 10 and
> I was wondering if clang/llvm 2.8 would do it.
Perhaps I better try the latest, got an error when I tried 2.8:
In file included from testsuite/test.cpp:8:
In file included from ./testsuite/precompile.h:4:
./util/precompile.h:17:12: fatal error: 'iosfwd' file not found
--
Øyvind Harboe - Can Zylin
2011 Jun 30
2
[LLVMdev] GCC 4.1 ABI and clang
On Thu, Jun 30, 2011 at 02:44:26PM +0200, Øyvind Harboe wrote:
> On Thu, Jun 30, 2011 at 2:03 PM, Duncan Sands <baldrick at free.fr> wrote:
> > Hi Øyvind,
> >
> >> I'm trying to find some written evidence to present to the powers
> >> that be that clang/llvm is ABI compatible with GCC 4.1 linux
> >> 64 bit.
> >
> > both clang and
2011 Jul 03
0
[LLVMdev] Deleting unused C++ code
An easier way would be to use a coverage tool like gcov to see what's
actually *used* when the app is run normally. Then you can ask the
question, what percentage of all lines of code are dead?
A static analysis will not be able to see through things like virtual
method calls.
Reid
On Sun, Jul 3, 2011 at 3:07 PM, Øyvind Harboe <oyvind.harboe at zylin.com> wrote:
> Can llvm
2011 Jun 30
4
[LLVMdev] GCC 4.1 ABI and clang
Hi Øyvind,
> I'm trying to find some written evidence to present to the powers
> that be that clang/llvm is ABI compatible with GCC 4.1 linux
> 64 bit.
both clang and gcc-4.1 are supposed to conform to the platform ABI (if they
don't then that is a bug), and thus be ABI compatible.
Ciao, Duncan.
2011 Jun 30
0
[LLVMdev] GCC 4.1 ABI and clang
On 30/06/11 15:13, Øyvind Harboe wrote:
>> Sorry, I meant from which version of clang? I'm using Ubuntu 10 and
>> I was wondering if clang/llvm 2.8 would do it.
>
> Perhaps I better try the latest, got an error when I tried 2.8:
C++ support in clang 2.8 was poor.
Ciao, Duncan.
>
> In file included from testsuite/test.cpp:8:
> In file included from
2011 Jul 04
2
[LLVMdev] Deleting unused C++ code
On Sun, Jul 3, 2011 at 10:34 PM, Reid Kleckner <reid.kleckner at gmail.com> wrote:
> An easier way would be to use a coverage tool like gcov to see what's
> actually *used* when the app is run normally. Then you can ask the
> question, what percentage of all lines of code are dead?
We need something that can do this using static analysis... Otherwise
we can just use Eclipse
2011 Jun 30
0
[LLVMdev] iosfwd problems
If you have not done so, you have to configure a clang header to find
your default libc++ header files. See #5 at http://clang.llvm.org/get_started.html
if this is your issue.
Garrison
On Jun 30, 2011, at 10:33, Øyvind Harboe wrote:
> I've tried llvm 2.8 and 2.9, but they both have problems with
> #include <iosfwd>.
>
> Any pointers to what this might be?
>
>
2011 Jun 30
2
[LLVMdev] GCC 4.1 ABI and clang
Hi,
I'm trying to find some written evidence to present to the powers
that be that clang/llvm is ABI compatible with GCC 4.1 linux
64 bit.
This would allow me to work with clang/llvm at my day-job and
I would like nothing better!
This is a pretty big app(millions of lines of code), so it would be
interesting to see how llvm/clang behaves.
Better warnings/errors and cutting down on build
2011 Jul 04
0
[LLVMdev] Deleting unused C++ code
On Mon, Jul 4, 2011 at 1:42 AM, Øyvind Harboe <oyvind.harboe at zylin.com> wrote:
> On Sun, Jul 3, 2011 at 10:34 PM, Reid Kleckner <reid.kleckner at gmail.com> wrote:
>> An easier way would be to use a coverage tool like gcov to see what's
>> actually *used* when the app is run normally. Then you can ask the
>> question, what percentage of all lines of code