similar to: RFC: Supported Optimizations attribute

śr., 5 gru 2018 o 00:22 John McCall via cfe-dev <cfe-dev at lists.llvm.org> napisał(a): > On 4 Dec 2018, at 17:50, Philip Reames wrote: > > Skimming along, apologies if I'm repeating something which already got > said. > > If I understand this correctly, the basic problem we're trying to solve is > to use a local hint (the invariant.group) to make a global

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

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 >

I think we should have some bounds on how "badly" a supported_optimizations tag on a function can affect its semantics. For instance, can a "supported_optimizations" invariant be that "the CFG is always structured"? Or (exaggerating to illustrate the point) "the function has an equal number of loads and stores"? -- Sanjoy On Mon, Dec 3, 2018 at 8:52 PM

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

> 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

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

Skimming along, apologies if I'm repeating something which already got said. If I understand this correctly, the basic problem we're trying to solve is to use a local hint (the invariant.group) to make a global assumption about other code which might exist elsewhere outside the function.  The attribute proposed can basically be phrased as describing a universe of functions within

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 -

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

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

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

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

Hi folks, I would like to ask for some help with handling invariant.group metadata for pointer comparison. Currently, we have a problem with devirtualization of this code: void compare() { A* a = new A; a->foo(); A* b = new(a) B; if (a == b) { b->foo(); } } Now because it is legal to replace b with an in the branch the vtable load will use old pointer operand

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