Displaying 20 results from an estimated 259 matches for "devirtualize".
2019 Dec 11
5
RFC: Safe Whole Program Devirtualization Enablement
...given pointer is associated with the given type
identifier (https://llvm.org/docs/LangRef.html#llvm-type-test-intrinsic).
It is currently inserted only for classes with hidden LTO visibility as the
implication of this sequence is that we have full visibility of that type’s
class hierarchy, and may devirtualize the call based on that knowledge.
This assumption is not valid if the class does not have hidden LTO
visibility.
In order to drive later devirtualization, we still need the type
compatibility information provided by the llvm.type.test, but want to delay
a decision on whether it is valid to assume...
2010 Oct 13
4
[LLVMdev] Missed devirtualization opportunities
...>>> 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...
2011 Dec 09
0
[LLVMdev] Implementing devirtualization
...a and successfully reconstruct the class
> hierarchy. Can anyone help with this?
>
> We're also open to alternative approaches, but we'd like to stay in LLVM
> IR as much as possible.
Implement field-sensitive interprocedural sparse conditional constant
propagation and it will devirtualize.
The reason I don't like having an explicit devirtualization pass is that
it requires a large amount of analysis (interprocedural, no less!) and
is strictly single-purpose. The way that LLVM does devirtualization now
is through a series of tons of tiny steps:
* the very last stage in dev...
2017 Dec 07
2
devirtualization with new-PM pipeline
Chandler et al,
I have been playing with the new PM pipeline, being particularly
interested in how it can handle devirtualization.
Now, I discovered what I believe is a "regression" vs old PM on a rather
simple one-translation-unit testcase.
clang is able to devirtualize it with -O3 and fails to do so with
-fexperimental-new-pass-manager added.
It looks like a pipeline issue, though I did not dig deeper as I'm not
sure if this kind of behavior
is expected at current stage of New PM life or not?
If it is not expected then I'ld be happy to file a bug and...
2010 Oct 14
0
[LLVMdev] Missed devirtualization opportunities
...;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...
2017 Dec 14
2
devirtualization with new-PM pipeline
...ew PM. The DevirtSCCRepeatedPass::run method
first scans the functions in the SCC to collect value handles for indirect
calls, runs the CGSCC pass pipeline and then checks if any of the call
value handles now point to a direct call, in which case it runs the
pipeline again (which should inline the devirtualized call) . The problem
is scanning the initial SCC for indirect calls is not enough since inlining
can produce indirect calls (which could then get devirtualized by later
passes). One (ugly) fix is to pass the value handles to the inliner
through CGSCCUpdateResult and let the inliner augment it as t...
2017 Nov 30
3
Question about visibility analysis for whole program devirtualization pass
Hi!
I have a question about whole program devirtualization pass. According to my understanding devirtualization is performed only for the classes that have hidden LTO visibility and this visibility is controlled by attributes in the source level or command line options. So visibility analysis is currently performed only in the front-end. But LLVM has LTO internalization pass that uses
2010 Oct 13
0
[LLVMdev] Missed devirtualization opportunities
...;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...
2011 Dec 08
4
[LLVMdev] Implementing devirtualization
Hello all,
Our compilers class has been using LLVM, and a partner and I decided to
implement devirtualization of virtual C++ calls in LLVM as a class project.
We quickly realized that existing debug metadata generated by Clang didn't
give us enough info to (precisely) implement this, and as such have already
begun modifying Clang to insert such metadata. However, for
devirtualization we also
2010 Oct 13
0
[LLVMdev] Missed devirtualization opportunities
...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...
2010 Oct 14
2
[LLVMdev] Missed devirtualization opportunities
...gt; 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...
2010 Oct 11
0
[LLVMdev] Missed devirtualization opportunities
On Oct 11, 2010, at 9:12 AM, Kenneth Uildriks wrote:
> 3. The front-end, recognizing that scribbling on an instance's vtbl
> pointer has undefined results, eliminated the loads of the vtbl
> pointer and replaced them with @classvtbl.TestVirtual. This would
> allow devirtualization within a function at least, but (I think) would
> do less to allow analysis to spot
2015 Feb 04
2
[LLVMdev] IR extension proposal: bitset constants
On Tue, Feb 03, 2015 at 04:03:45PM -0800, Sean Silva wrote:
> One other thing: if this can be used for control-flow integrity, I assume
> it has to have good knowledge of the available indirect call targets. Could
> we also use this information for devirtualization?
I would expect so. If a bitset contains only one element, we should be able
to teach the lowering pass to simply test that
2017 Dec 06
2
Question about visibility analysis for whole program devirtualization pass
Hi Peter,
Thanks for the reply. I agree that the base class vtable may be not referenced by a derived class. However, the vtable of a derived class has to reference its parent type_info, and so having type_info internalized means that the class is final, doesn’t it?
Thanks,
Nikolai
From: Peter Collingbourne [mailto:peter at pcc.me.uk]
Sent: Wednesday, December 6, 2017 4:36 AM
To: Gainullin,
2018 Mar 20
0
[cfe-dev] RFC: Devirtualization v2
Sounds like it works!
Basically, adding these extra strip.invariant.group calls before pointer
comparisons breaks the transform that was problematic. Presumably, clang
would only strip invariant groups from pointers to dynamic types before
casting them or using them in a comparison, so that the value equivalence
optimization still works in the general case. The proposal trades value
equivalence
2015 Jan 07
2
[LLVMdev] Inclusion of iostream affects devirtualization in release_35
Hello,
I've stumbled upon the following behavior in branches/release_35 (as of
218689) under ubuntu 14.04 LTS amd64: whenever I include the (system-wise)
gnu iostream header, clang++ stops devirtualizing the following code:
#if BREAKAGE_ENSUES
#include <iostream>
#endif
struct Base {
virtual int foo() const = 0;
};
struct A : Base {
int a;
A(const int a)
: a(a) {
}
int foo() const
2010 Oct 13
3
[LLVMdev] Missed devirtualization opportunities
...ess 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've been thinking about how to better take the invariant regions into
account, and it quickly became clear that it would be easier to handle
i...
2016 Jun 20
2
Intended behavior of CGSCC pass manager.
...nd then calls a virtual
> function on the instance, then the virtual function being called and
> the constructor will have been maximally simplified (F refs the
> constructor, and the constructor refs all the virtual functions), and
> you're more likely to inline the constructor and devirtualize the
> call. I don't have any real data to back up that this will materially
> help, though.
Sanjoy, this is a good example. The code pattern is basically like this:
Worker(Base *B) {
B->vCall();
}
Factory::create(Kind K) {
if (K == ..) return new D1();
else ...
}
Calle...
2010 Oct 11
4
[LLVMdev] Missed devirtualization opportunities
...ntptr %class.TestVirtual* %pinstance, i64 0, i32 0
; Populate the instance's vtbl pointer. After this, the instance is
constructed.
store %classvtbltype.TestVirtual* @classvtbl.TestVirtual,
%classvtbltype.TestVirtual** %ppVtbl
; If this next call is commented out, the virtual method call is
devirtualized by -std-compile-opts
%puts = call i32 @puts(i8* getelementptr inbounds ([2 x i8]* @str, i32
0, i32 0))
; Call the virtual function.
; load the instance's vtbl pointer.
%pVtbl1 = load %classvtbltype.TestVirtual** %ppVtbl
; load the function pointer from the vtbl
%ppVfn1 = getelementptr %cla...
2010 Oct 14
0
[LLVMdev] Missed devirtualization opportunities
...ey 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?
>>>>
&g...