[LLVMdev] Deleting unused C++ code

Daniel Berlin dberlin at dberlin.org
Sun Jul 3 23:04:25 PDT 2011

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 are dead?
> We need something that can do this using static analysis... Otherwise
> we can just use Eclipse and search for reference as a first approximation
> and try a rebuild. Tedious process. gcov is out of question we'd have
> to execute the entire program, which is a non-starter.
> That said, it would be interesting to add gcov to the testsuite to get a measure
> of how many percent of the application we're exercising....
>> A static analysis will not be able to see through things like virtual
>> method calls.
> Not even in theory?

It's provably undecidable to do so in general, because aliasing is
statically undecidable.
(and the more complicated paper it cites by Landi).

This is not to say it's not possible to resolve any of them sometimes,
it means in general you will not be able to.
There are a number of static analysis to do things like class
hierarchy resolution which may be able to prove which classes some
virtual calls will call.
It does generally require you assert to the compiler that you will not
change the class hierarchy later (through dynamic loading/etc), or
else you need to redo the analysis at that point.  It is also meant
for compiler optimization, not code coverage. It's purpose is to get
good enough results fast, so that even if it can't resolve a call, it
may let you eliminate other possibilities and make guarded direct

Basically, what you are trying to do (statically decide code coverage)
is statically impossible, and one can probably prove you can't even
probabilistically estimate it to within some reasonable factor.

More information about the llvm-dev mailing list