similar to: RFC: Safe Whole Program Devirtualization Enablement

<font face="Verdana,Arial,Helvetica,sans-serif" size="2"> <span><div>Hi,<br>There was a mention of optimizing away C++ dynamic_casts in LTO in this presentation: <a href="https://www.youtube.com/watch?v=Fd3afoM3UOE&t=1306" target="_blank">https://www.youtube.com/watch?v=Fd3afoM3UOE&t=1306</a><br>I

Hi all, I'd like to make the following proposal to implement an optimization called virtual constant propagation. ==Introduction== After enabling control flow integrity protection in Chromium, we have observed an unacceptable performance regression in certain critical layout microbenchmarks. Profiling [0] revealed that the cause of the regression was a large number of virtual calls, each

The proposed mitigation for variant 2 of CVE-2017-5715, “branch target injection”, is to send all indirect branches through an instruction sequence known as a retpoline. Because the purpose of a retpoline is to prevent attacker-controlled speculation, we also end up losing the benefits of benign speculation, which can lead to a measurable loss of performance. We can regain some of those benefits

Hi all, I'd like to make a proposal to implement the new vtable ABI described in PR26723, which I'll call the relative ABI. That bug gives more details and justification for that ABI. The user interface for the new ABI would be that -fwhole-program-vtables would take an optional value indicating which aspects of the program have whole-program scope. For example, the existing

Wouldn't a branch funnel open the door to a type 1 attack? E.g. if the code looks like this, then a branch funnel basically turns into a standard type 1 pattern AFAICT: struct Base { virtual int f(long) = 0; }; struct A : Base { int f(long x) override { return 0; }; }; struct B : Base { int f(long x) override { // As in listing 1 in

Hi, Sean Silva via llvm-dev wrote: > Wouldn't a branch funnel open the door to a type 1 attack? Only if the code looks exactly as you wrote it. If I understand this correctly the problem with indirect branches is that the "gadget", the code leaking the data, could be *anywhere* in the binary, giving the attacker much more freedom. So restricting these calls to one of the

Hi, I just thought about another use case: VTable compression. If you know that an entry in the Vtable is never used, just remove it! I’d hope we could even eliminate some unused virtual functions from the final binary. — Mehdi > On Jan 27, 2016, at 10:29 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Peter, > > Pete (Cooper, CC'ed) had a

Using relative offsets applies to more than just vtables. It would do wonders for constant strings too. -- Sean Silva On Mon, Feb 29, 2016 at 1:53 PM, Peter Collingbourne via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Hi all, > > I'd like to make a proposal to implement the new vtable ABI described in > PR26723, which I'll call the relative ABI. That bug gives more

Hi all, I wanted to make this proposal to extend ThinLTO to allow a bitcode module to embed another bitcode module containing summary information. The purpose of doing so is to support CFI and whole-program devirtualization optimizations under ThinLTO. Overview The CFI and whole-program devirtualization optimizations work by transforming vtables according to the class hierarchy. For example,

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,

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

Hi Peter, Thanks for your answer! > On Jan 28, 2016, at 10:17 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > Hans wrote: >> (and start-up time if we can drop the vtables and >> void the dynamic relocations). > > On Thu, Jan 28, 2016 at 09:15:05AM -0800, Mehdi Amini wrote: >> Hi, >> >> I just thought about another use case: VTable

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

> On Mar 19, 2018, at 7:27 PM, Piotr Padlewski via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > Hi folks, > > here is a link to the proposal that we've been working on lately: > https://docs.google.com/document/d/16GVtCpzK8sIHNc2qZz6RN8amICNBtvjWUod2SujZVEo/edit?usp=sharing

Hi John, 2018-03-28 23:23 GMT+02:00 John McCall <rjmccall at apple.com>: > > > On Mar 19, 2018, at 7:27 PM, Piotr Padlewski via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > > Hi folks, > > here is a link to the proposal that we've been working on lately: > https://docs.google.com/document/d/16GVtCpzK8sIHNc2qZz6RN8am >

Hi folks, here is a link to the proposal that we've been working on lately: https://docs.google.com/document/d/16GVtCpzK8sIHNc2qZz6RN8amICNBt vjWUod2SujZVEo/edit?usp=sharing But for the record, I also paste it here. Feedback will be really appreciated!

Mike Stump wrote: > On Mar 24, 2009, at 10:22 AM, Luke Dalessandro wrote: > >> I guess that alias analysis doesn't always "trust" casts, where if I >> manually >> pushed back I would be assuming that the casts are correct? > > Once all the pushing is in, one should be able to discover that the > casts all convert to the same type, and remove

Hi all, I would like to propose a mechanism that allows IR modules to co-operatively build a pointer set corresponding to addresses within a given set of globals. The specific use case I have in mind is to provide a mechanism for a C++ program to efficiently verify (at each call site) that a vtable pointer is in the set of valid vtable pointers for the class or its derived classes. One way of

Hi all, The bitset metadata currently used in LLVM has a few problems: 1. It has the wrong name. The name "bitset" refers to an implementation detail of one use of the metadata (i.e. its original use case, CFI). This makes it harder to understand, as the name makes no sense in the context of virtual call optimization. 2. It is represented using a global named metadata node, rather than

On Fri, Mar 4, 2016 at 2:48 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > On Mon, Feb 29, 2016 at 1:53 PM, <> wrote: >> >> @A_vtable = {i8*, i8*, i32, i32} {0, @A::rtti, @A::f - (@A_vtable + 16), >> @A::g - (@A_vtable + 16)} >> > > There's a subtlety about this aspect of the ABI that I should call > attention to. The virtual function