similar to: Handling invariant.groups with equality + marking it as experimental

Hi Piotr, On Thu, May 4, 2017 at 6:44 AM, Piotr Padlewski <piotr.padlewski at gmail.com> wrote: > Also, Sanjoy proposed to mark invariant.group features as experimental, so > we will not be afraid to break behavior of frontends that already use it. > > Right now I am pretty sure that clang is the only one that curently uses it > (and not by default). Firstly, yes, I think we

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

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

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

2017-04-01 15:59 GMT+02:00 Piotr Padlewski <piotr.padlewski at gmail.com>: > > > 2017-03-31 23:20 GMT+02:00 Sanjoy Das <sanjoy at playingwithpointers.com>: > >> Hi Piotr, >> >> On March 31, 2017 at 1:07:12 PM, Piotr Padlewski >> (piotr.padlewski at gmail.com) wrote: >> > [snip] >> > Do I understand it correctly, that it is legal to

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

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

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

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 Piotr, On March 31, 2017 at 1:07:12 PM, Piotr Padlewski (piotr.padlewski at gmail.com) wrote: > [snip] > Do I understand it correctly, that it is legal to do the hoist because all > of the instructions above %vtable does not throw? Yes, I think you're right.  HeaderMayThrow is a conservative approximation, and the conservativeness is biting us here. > Are there any plans to

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 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 Fri, Jul 31, 2015 at 3:53 PM, Philip Reames <listmail at philipreames.com> wrote: > > Quoting from the google doc: "If we don’t know definition of some > function, we assume that it will not call @llvm.invariant.group.barrier(). > " > This part really really bugs me. We generally try to assume minimal > knowledge of external functions (i.e. they can do

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

Define soon? My guess is 1 year or less. (I've already seen patches to start converting most remaining memdep uses, like memcpy opt, licm, etc) On Fri, Dec 23, 2016 at 8:27 AM, Piotr Padlewski via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > 2016-12-23 17:22 GMT+01:00 Davide Italiano <davide at freebsd.org>: > >> On Fri, Dec 23, 2016 at 8:12 AM, Piotr

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!

> 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