similar to: 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,

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

> Are you suggesting that we should be more aggressive by default (i.e. without -fvisibility=hidden or any new options)? > I believe that will be too aggressive for class LTO visibility. > It is common to override a virtual functions across shared library boundaries I'm myself a fan of GCC's conservative approach so I'd agree with you on that. But regardless of my personal

On Wed, Dec 18, 2019 at 3:38 AM Iurii Gribov via llvm-dev < llvm-dev at lists.llvm.org> wrote: > (Readding Hal) > > > Are you suggesting that we should be more aggressive by default (i.e. > without -fvisibility=hidden or any new options)? > > I believe that will be too aggressive for class LTO visibility. > > It is common to override a virtual functions across

(cc list this time) Hi Teresa, Apologies if this has been discussed before but ... > The LTO visibility of a class is derived at compile time from the class’s symbol visibility. > Generally, only classes that are internal at the source level (e.g. declared in an anonymous namespace) receive hidden LTO visibility. > Compiling with -fvisibility=hidden tells the compiler that, unless

Hi, On 13 Jul 2015, at 15:59, Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote: ----- Original Message ----- From: "Artur Pilipenko" <apilipenko at azulsystems.com<mailto:apilipenko at azulsystems.com>> To: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu> Cc: "Hal Finkel" <hfinkel at anl.gov<mailto:hfinkel at

> On Jul 14, 2015, at 4:48 PM, Reid Kleckner <rnk at google.com> wrote: > > This sounds more like a use case for metadata. Can we attach metadata to function arguments, or does that not work currently? We can’t, no. I have an out of tree patch which allows metadata in AttributeSets. This would also potentially also work here. However, depending on the number of unique

Hi, I’d like to support string attributes on function arguments and return values. We are going to use them in our tree to express higher level language types. Internally attributes framework have everything to do this, it’s even possible to generate string attributes via API right now: Function *function; function->setAttributes(function->getAttributes().addAttribute(context, i,

On Tue, Jul 14, 2015 at 9:01 PM Philip Reames <listmail at philipreames.com> wrote: > On 07/14/2015 05:07 PM, Pete Cooper wrote: > > > On Jul 14, 2015, at 4:48 PM, Reid Kleckner <rnk at google.com> wrote: > > This sounds more like a use case for metadata. Can we attach metadata to > function arguments, or does that not work currently? > > We can’t, no.

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,

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

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

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

On Wed, Oct 13, 2010 at 11:16 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > 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 >>>>>

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

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

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

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

I took the output of clang, simplified it, and used it as a testbase. Essentially, there is one class with one virtual function; I create an instance and call the virtual method all in one function: ; The TestVirtual class vtbl @classvtbl.TestVirtual = constant %classvtbltype.TestVirtual { ; Pointers to the virtual methods for the TestVirtual class ... } ; ... define i32 @main() nounwind { ;