[LLVMdev] Missed devirtualization opportunities

[Kenneth Uildriks]

On Wed, Oct 13, 2010 at 6:49 PM, John McCall <rjmccall at apple.com> wrote:
>
> 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.
But I believe the language does allow "undefined behavior" if there's
a use of pT when the pointed-to object isn't actually of type T.  It's
an invalid use in that case, right?