[LLVMdev] Missed devirtualization opportunities

[Kenneth Uildriks]

On Wed, Oct 13, 2010 at 12:45 AM, Nick Lewycky <nicholas at mxc.ca> wrote:
> Kenneth Uildriks wrote:
>>>
>>> You're right, I hadn't thought this through. The whole point of making
>>> them
>>> local is to say that "I'm sure these callees won't modify that memory"
>>> regardless of what functions actually get called, even indirectly. We
>>> can't
>>> know that they won't modify the vptr in advance, so invariant doesn't
>>> work
>>> here. Making it non-local just means that we would need to know the
>>> static
>>> call graph, which we don't because we haven't devirtualized yet so all
>>> the
>>> calls are indirect.
>>> Nick
>>
>> So that means you're now saying that llvm.invariant.end ought to be
>> left the way it is, right?
>
> I have no idea how to make use of llvm.invariant to help devirtualization.
> If no use or other use case for them can be found, maybe they should be
> removed.

Apply invariant to the vtpr as long as the corresponding instance
pointer is in use within a function.  With an invariant vtpr (and
better invariant support, and a front-end that uses it),
devirtualization happens more or less automatically with
-std-compile-opts.

Do the same wherever an instance pointer is passed.  Mark its
corresponding vtpr invariant from the beginning of the entry block
until right after the last use of the instance pointer.  Then a few
simple improvements to inlining & partial specialization will give you
some interprocedural devirtualization.

Anyway, you convinced me a few messages ago that invariant.end really
should be left the way it is.  Especially since assuming invariance
hasn't ended when it has is unsafe... we *must* be able to match an
invariance start to its corresponding invariance end in all cases.