similar to: [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

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

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.

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

I think what you're looking for is something like Doxygen or CodeViz that can generate (imperfect) call graphs for you. It sounds like you just need a rough list of functions that might be unused to start with. -Scott On Sun, Jul 3, 2011 at 11:04 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > On Mon, Jul 4, 2011 at 1:42 AM, Øyvind Harboe <oyvind.harboe at zylin.com>

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/

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

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.

> 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

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

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? > >

>> Starting with which version? > > I think GCC last changed the C++ ABI with version 3.4. 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. clang --version clang version 2.8 (branches/release_28) -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87

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

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

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

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

On Fri, 20 Jun 2008, [ISO-8859-1] ?yvind Harboe wrote: >> The ZPU has two instructions that I'd also like to use. These instructions >> can push a value from deeper down on the stack and also pop a value >> from the stack and store them deeper down on the stack. > > Sounds like the Intel X87 floating point stack, which we support. GCC does as well. Supporting floating

> ?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

On Mon, Jul 4, 2011 at 9:46 AM, Scott Conger <scott.conger at gmail.com> wrote: > I think what you're looking for is something like Doxygen or CodeViz > that can generate (imperfect) call graphs for you. It sounds like you > just need a rough list of functions that might be unused to start > with. I'll have a peek at CodeViz. Even a first approximation of unused code

> 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. >