[cfe-dev] -Wunreachable-code and templates

[David Blaikie]

On Tue, Jan 10, 2012 at 7:55 AM, Ted Kremenek <kremenek at apple.com> wrote:
> On Jan 10, 2012, at 12:20 AM, David Blaikie wrote:
>
> By repeatedly, you mean in each translation unit, right? Because we
>
> shouldn't have to visit them more than once per TU (we won't be
>
> visiting them per insntantiation). But, yes, the idea of analyzing
>
> every boost template someone includes when they're only using a subset
>
> does sound a little costly - I might be interested to compare times,
>
> though.
>
>
> Only analyzing instantiated templates (& keeping a list of those
>
> templates we've already seen/analyzed) seems OK to me, assuming that
>
> didn't represent a prohibitive memory cost to maintain the set of
>
> visited templates (can't see why it should, but it is a small
>
> time/space tradeoff all the same).
>
>
> Is there a particular technique/suite/process I should use to try to
> measure the possible performance regression of performing reachable
> code analysis on all templates? (of course I may need to come up with
> my own test cases using the STL and/or boost to really grind things a
> bit)
>
>
> Two thoughts:
>
> (1) My main concern is Boost and STL, which are commonly used.  If you
> notice a significant performance regression on code that uses either, that's
> very concerning.  What kind of performance loss are you seeing on your test
> cases?

I haven't done any perf analysis yet - I was asking if there was any
recommended approach I should be using to make such measurements.

I'll take this answer as implying that there probably isn't much &
I'll have a first blush at making my own ad-hoc measurements. I'll
repost here once I have any numbers I think might be useful.

> (2) As a performance optimization, we could only analyzing uninstantiated
> templates that are actually instantiated.  This means that some code won't
> get checked immediately, but doing otherwise doesn't seem to match the
> "pay-for-what-you-use" model of C++.  That could recover some of the
> performance loss being observed in (1) to the point where things are
> acceptable.

Yep - I get that, but wanted to have some clear numbers for the perf
impact before I went about writing such an optimization.

It'd also be interesting to know the memory footprint (since this
optimization will increase space usage somewhat) so if there are any
techniques/accepted processes for measuring memory usage of Clang to
assess that sort of situation I'm all ears too.

Thanks,
- David