search for: devirtualization

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 requiring -fvisibility=hidden at compile time, by pre-enabling bitcode for whole progr...

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

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 insert such metadata. > However, for devirtualizatio...

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

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

...2017 at 12:20 PM, Fedor Sergeev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 12/07/2017 11:09 PM, Fedor Sergeev via llvm-dev wrote: > > 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. > > I hate to correct myse...

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

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

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 need to re...

...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. > 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 we scanned forward instead of backwards. Right, th...

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

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 devirtualization opportunities > across functions. (Although ArgPromotion could arrange to have the > vtbl pointer passed in separately, and then inlining and/or partial > specialization could be made t...

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 the given pointer is equal to that element (i.e. the only valid vptr). If the later IR branches to a trapping block if that condition is false, it should be possible for the...

...he 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, Artur <artur.gainullin at intel.com> Cc: llvm-dev at lists.llvm.org Subject: Re: Question about visibility analysis for whole program devirtualization pass Hi Artur, Unfortunately, making a visibility analysis at that level would not always give correct results because the symbol information provided by the linker is insufficient to make determinations about which type hierarchies are closed at LTO time. For example, consider a main program wit...

...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 power for more devirtualization power. One downside is that it may add many new IR instructions, but I don't see how to avoid them, as the whole point is to create distinct Value objects for use in the pointer equality comparison. On Mon, Mar 19, 2018 at 4:31 PM Piotr Padlewski via cfe-dev < cfe-dev at lists.llvm.org>...

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

> 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

On Sun, Jun 19, 2016 at 12:01 AM, Sanjoy Das <sanjoy at playingwithpointers.com > wrote: > Hi David, > > Xinliang David Li wrote: > >> I believe it is primarily used for ordering the visitation of > CallSCC's (i.e. SCC's in the "call graph"). > > This is what it can do -- but what benefit does it provide? > > One benefit is that once you

...ayBeCaptured gets called on it when the @puts call is encountered and returns true because %pinstance is passed through %pVfn1 to make the virtual method call, and the call to %pVfn1 (unlike the actual function that %pVfn1 must point to) does not declare the 'this' parameter nocapture. The devirtualization could have happened anyway if one of the following had happened: 1. PointerMayBeCaptured was able to determine that the possible capture happened *after* the call to @puts. PointerMayBeCaptured does not expose a parameter for the instruction we're trying to getModRefInfo on (the @puts call),...

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