[LLVMdev] Missed devirtualization opportunities

[John McCall]

On Oct 13, 2010, at 4:35 AM, Kenneth Uildriks wrote:

> 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.

Even if this works, it still requires us to inline the constructor to do any good.
And as long as llvm.invariant is defined in terms of memory (in C++ standards
parlance, "storage"), it won't work, because the language doesn't actually
guarantee that the memory is invariant.

John.