search for: devirtualized

Please send any comments. As mentioned at the end I will follow up with some patches as soon as they are cleaned up and I create some test cases. RFC: Safe Whole Program Devirtualization Enablement =================================================== High Level Summary ------------------ The goal of the changes described in this RFC is to support aggressive Whole Program Devirtualization without

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

Vitor Luis Menezes wrote: > 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

...  int virt1() override {     return 20;   } }; static int redirect(A* a) {   return a->virt1(); } int calc() {   B b;   return redirect(&b); } ] clang++ -O3 devirt.cpp -std=c++11 -S -emit-llvm -o - ... define i32 @_Z4calcv() local_unnamed_addr #0 { entry:   ret i32 20    <--- nicely devirtualized (&b)->virt1() call } ... ] clang++ -O3 -fexperimental-new-pass-manager -std=c++11 -S -emit-llvm -o - ... define i32 @_Z4calcv() local_unnamed_addr #0 { entry:   %b = alloca %struct.B, align 8   %0 = bitcast %struct.B* %b to i8*   call void @llvm.lifetime.start.p0i8(i64 8, i8* nonnull %0)...

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

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

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

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

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

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

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

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

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

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,

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

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

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

...e *B = Factory::create(K, ...); Worker(B); } The added ordering constraints from Factory::create() node to all virtual methods in Base's hierarchy ensures that after 1) Factory::create gets inlined to Caller, and 2) Worker(..) method gets inlined to Caller, and 3) newly exposed vcall gets devirtualized the inliner sees a callee to say D1::vCall which is already simplified. However, in real applications, what I see is the following pattern (for instances LLVM's Pass ) Caller() { Base *B = Factory::create(...); Stash (B); // store the object in some container to be retrieved later...

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

...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? >>>> &gt...