similar to: [GSoC] Devirtualization v2

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

> 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

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

> 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

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

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 all, I have a question about dereferenceable metadata on load instruction. I have a patch (https://reviews.llvm.org/D31539) for LICM that hoists loads with !invariant.group. The motivation example is devirtualization: struct A { virtual void foo(); }; int bar(); void indirect(A &a) { while(bar()) a.foo(); } With -O2 -fstrict-vtable-pointers we get: define void

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 makes sense. Modulo bitcasts, the invariant is identified by a >> particular pointer SSA value. Given that you can't sensibly have two >> nonequivalent

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

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

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

There are another things left: 1. Adding check for ubsan to detect UBs caused by inplace new 2. upgrading GVN to optimize based on !invariant.group across BBs 3. Adding something like "nocapture-global" that will say that this pointer is not being captured by global, but may be captured for example by returning it from function. This thing is important because this is exactly what

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 all, I would like to propose a new way clang would decorate vtable loads in order to handle devirtualization better. I've added *llvm-dev* also, because this can start a discussion about changing invariant.group to just invariant. PDF version of this RFC can be found here: https://drive.google.com/file/d/0B72TmzNsY6Z8ZmpOUnB5dDZfSFU/view?usp=sharing Background: Initial old design:

Hi folks, I would like to work on the implementation of "Devirtualization v2" proposal that I have shared a week ago. This mail is more like a FIY, because naturally, I don't have any questions about the project I propose myself :) Here you can see my GSoC proposal: https://docs.google.com/document/d/1QuxV4MVqP3Qa5RBgrC4SoWSPEj0dvAB6jFeSr8yA4LQ/edit?usp=sharing and here the RFC:

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

On Fri, Mar 31, 2017 at 10:23 AM, Sanjoy Das <sanjoy at playingwithpointers.com > wrote: > Hi Piotr, > > On March 31, 2017 at 9:07:42 AM, Piotr Padlewski > (piotr.padlewski at gmail.com) wrote: > > Hi all, > > I have a question about dereferenceable metadata on load instruction. I > > have a patch (https://reviews.llvm.org/D31539) for LICM that hoists >

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

> I suspect #2 is the right design, mostly because I suspect most of the interesting and important inference cases are going to be cases where we can easily infer the stronger guarantee, and once inferred we will have much more freedom to optimize based on this stronger guarantee... Can't the stronger guarantee be represented in the existing system by either: * Adding 'readonly'