similar to: [GSoC] 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

Hi Piotr, You may be interested in a recent patch I posted: http://reviews.llvm.org/D11043 This patch addresses a de-virtualization case that I’m not sure would be handled by your current proposal, namely that of a virtual call where the ‘this’ object is a global variable. For example: struct A { A(); virtual void foo(); }; void g(A * a) { a->foo(); } A a; int main()

Hi Piotr, Thanks for posting this! First, a question. When you say, regarding i8* @llvm.invariant.group.barrier(i8*): "Required to handle destructors, placement new and std::launder. Call of this function will be put on the end of each of this functions" I completely understand placement new and std::launder. I don't understand destructors, could you explain? Also, am I correct

HI, Yep, our proposal doesn't cover it, because this load ; icmp ; assume; will land global initilizer function, and main will not see it. At least if foo would be called multiple times, then we would only have one load from vtable, but unfortunatelly we will not be able to inline, or make direct call to it with this approach. I think that this case is rare enough to solve it right now. Piotr

On Thu, Jul 23, 2015 at 11:42 AM, Piotr Padlewski <prazek at google.com> wrote: > HI, > Yep, our proposal doesn't cover it, because this load ; icmp ; assume; > will land global initilizer function, and main will not see it. > At least if foo would be called multiple times, then we would only have > one load from vtable, but unfortunatelly we will not be able to inline,

> 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

On Sat, Jul 25, 2015 at 12:39 PM, Hal Finkel <hfinkel at anl.gov> wrote: > Hi Piotr, > > Thanks for posting this! First, a question. When you say, regarding i8* > @llvm.invariant.group.barrier(i8*): > > "Required to handle destructors, placement new and std::launder. Call of > this function will be put on the end of each of this functions" > > I

Having read through the proposal, I feel like I missing some of the background to understand the problem you're trying to solve. My mental model is that construction of an object creates a new abstract location in an infinite heap with each object infinitely far apart. Destruction of the object destroys the abstract location. As a result, destructing one object and constructing another

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, please check out our RFC: Supported Optimizations attribute https://docs.google.com/document/d/1s0n-JVaSNML1Z9SCZVg2bgisxswIJAK2Tp9DahucW10/edit?usp=sharing Pasting it here for the record: RFC: supported_optimizations attribute Piotr Padlewski - piotr.padlewski at gmail.com Krzysztof Pszeniczny - kpszeniczny at google.com December 2018 Introduction Sometimes a possible class of

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!

Hi folks, my GSoC proposal for implementation of the RFC: Devirtualization v2 has been accepted and I already started coding a month ago. Some patches are already in clang and llvm. Right now I am finishing implementing strip.invariant.group intrinsic, but mostly I spend time debugging some segfaults that happen with -fstrict-vtable-pointers. If you are interested in the topic and would like to

> On Mar 30, 2018, at 10:36 AM, Piotr Padlewski <piotr.padlewski at gmail.com> wrote: > 2018-03-29 18:01 GMT+02:00 John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>>: >> On Mar 29, 2018, at 9:12 AM, Piotr Padlewski <piotr.padlewski at gmail.com <mailto:piotr.padlewski at gmail.com>> wrote: >> 2018-03-28 23:23 GMT+02:00 John McCall

Ok, replying anew now that I understand why reasoning about abstract locations for each object doesn't work. The general idea of describing a set of load and stores which belong to a particular invariant group seems reasonable. I've got some questions/comments on the specifics, but the overall direction seems entirely workable for the specific problem you're trying to solve.

Hi folks, this summer I will work with Richard Smith on clang devirtualization. Check out our proposal: https://docs.google.com/document/d/1f2SGa4TIPuBGm6y6YO768GrQsA8awNfGEJSBFukLhYA/edit?usp=sharing And modified LangRef http://reviews.llvm.org/D11399 You can also check out previous disscussion that was started before our proposal was ready -

On 01/28/2017 10:36 AM, Piotr Padlewski wrote: > > > 2017-01-26 15:41 GMT+01:00 Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>>: > > > On 01/26/2017 06:44 AM, Piotr Padlewski wrote: >> >> >> 2017-01-26 3:28 GMT+01:00 Richard Smith <richard at metafoo.co.uk >> <mailto:richard at metafoo.co.uk>>: >>

Hi Piotr, I think makes sense. Modulo bitcasts, the invariant is identified by a particular pointer SSA value. Given that you can't sensibly have two nonequivalent invariants associated with the same pointer SSA value simultaneously, there's no need to also identify the invariant with a metadata string as well. When we need a new "identifier" for the pointed-to value, we

2018-03-29 18:01 GMT+02:00 John McCall <rjmccall at apple.com>: > On Mar 29, 2018, at 9:12 AM, Piotr Padlewski <piotr.padlewski at gmail.com> > wrote: > 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: >> *Note that adding

> On Mar 29, 2018, at 9:12 AM, Piotr Padlewski <piotr.padlewski at gmail.com> wrote: > 2018-03-28 23:23 GMT+02:00 John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>>: >> On Mar 19, 2018, at 7:27 PM, Piotr Padlewski via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: >> Note that adding calls to strip and

2017-01-26 15:41 GMT+01:00 Hal Finkel <hfinkel at anl.gov>: > > On 01/26/2017 06:44 AM, Piotr Padlewski wrote: > > > > 2017-01-26 3:28 GMT+01:00 Richard Smith <richard at metafoo.co.uk>: > >> On 25 January 2017 at 15:03, Hal Finkel via cfe-dev < >> cfe-dev at lists.llvm.org> wrote: >> >>> Hi Piotr, >>> >>> I think