[cfe-dev] -Wunreachable-code and templates

[David Blaikie]

On Tue, Jan 10, 2012 at 10:07 AM, Ted Kremenek <kremenek at apple.com> wrote:
> On Jan 10, 2012, at 8:46 AM, David Blaikie wrote:
>
> 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.
>
>
> That's not quite the message I was trying to convey.  :)

Ah - sorry for the misunderstanding.

> As a first pass, I was wondering if you had observed anything noticeable
> before digging deeper.

Thanks for the clarification. All I've really done so far is run the
basic regression tests ('make test') & I didn't even look at the time
very closely - but it didn't pull the compiler to a
noticeable/ridiculous crawl.

> I'd approach this as follows:
>
> (1) Try running turning the warning on by default and run it through all of
> our benchmark tests, e.g. the GCC testsuite, clang tests, etc.  See if there
> is a performance regression there.  We regularly do this when measuring
> compile time regressions.

I'll look into how to run the GCC testsuite (I assume it's documented
somewhere on the Clang website) & the clang tests are just 'make test'
or some other tests I should find?

I was also curious about how you measure performance - I can simply
run "time make test" and look at the user+sys time spent though I was
wondering if there were particular tools/techniques to reduce noise,
particular margins of error/thresholds that are used, etc.

> (2) Try building a few real world C++ codebases that are known to use
> templates (or otherwise make heavy use of C++) with this warning, e.g.
> Clang, Boost, Blender, Qt and see if there is a noticeable compile-time
> regression.
>
> (3) While doing (2), see if the results of the warning (if any) are
> acceptable.

Yep - sounds like I've got some issues to work out just in terms of
correctness anyway (as you suspected, the CFG code might not be
entirely up to handling uninstantiated templates - I'll see if it's
very far off) that some more extensive testing would expose. I'll see
what comes up.

> This is a fair amount of work, but it's the kind of thing we need to do to
> make this warning production quality.

Fair enough. I suppose one day, ideally, these sort of payloads would
become part of some amount of automated (infrequent and/or opt-in)
regression validation that would make this work a bit smoother.

- David