[LLVMdev] Missed devirtualization opportunities

[Kenneth Uildriks]

> Correct.  Basically, the standard lets us assume that — if we know the dynamic
> type of an object at a certain point for some reason — that dynamic
> type is fixed when accessed through that pointer.
>
> Like the type-aliasing rules, this is probably one of those things that we need
> to be a little careful about taking advantage of, because even conscientious
> users are going to write their code around assumptions of what a
> "reasonable compiler" is going to optimize.
>
> John.

You've got a point there.  I know I get a little cranky when my code
*usually* works and I can't figure out why.

But still... there's an awful lot of class and function templates out
there that mainly seem to be there to force devirtualization.  The
Boost libraries are loaded with them.  I'd really like to see the need
for that go away.  Not to mention that even in the cases where we
can't narrow down a virtual call to one function, if we can narrow it
down to a finite set, we can construct a better callgraph and take
better advantage of interprocedural optimizations.

Maybe after I finish working on invariant support, I'll take a look at
clang's "undefined behavior checking" open project... that should
encourage enabling more aggressive assumptions over the long run.