llvm dev - May 2017 - 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 should definitely make the barrier stuff
experimental.  I don't think it has been ironed out enough for
generally use.

Secondly, at this point I'm wondering if the barrier/invariant.group
is the right abstraction at all.  Are there other designs you
considered early on that we can revisit in the light of these issues?

-- Sanjoy

2017-05-08 20:51 GMT+02:00 Sanjoy Das <sanjoy at playingwithpointers.com>:
> 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 should definitely make the barrier stuff
> experimental.  I don't think it has been ironed out enough for
> generally use.
Oh right, I will post patch that will mention it in the LangRef this week
and see if there will be any objections.

Secondly, at this point I'm wondering if the
barrier/invariant.group
> is the right abstraction at all.  Are there other designs you
> considered early on that we can revisit in the light of these issues?
>
> -- Sanjoy
>
I don't think there were any other ideas for propagation of the
"invartianess" of the vptr -
@Richard or @Nick, did you have any other ideas before my internship?


I am open to hear any other ideas for the model - even if they would be not
checked it might be a good inspiration.
Right now the only problem with the current model for devirtualization
(that we have seen) is the propagation
of the pointers from comparision. It is also the problem that we knew
almost from the beginning.
@Sanjoy, maybe you have some ideas how the semantics of the
!invariant.groups with propagation
of the pointers could be specified in a way that it would not brake the
testcases?


Piotr
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170509/2c95de05/attachment.html>

Hi folks,
friendly ping about this issue.

Piotr

2017-05-09 0:39 GMT+02:00 Piotr Padlewski <piotr.padlewski at gmail.com>:
>
>
> 2017-05-08 20:51 GMT+02:00 Sanjoy Das <sanjoy at
playingwithpointers.com>:
>
>> 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 should definitely make the barrier stuff
>> experimental.  I don't think it has been ironed out enough for
>> generally use.
>
> Oh right, I will post patch that will mention it in the LangRef this week
> and see if there will be any objections.
>
> Secondly, at this point I'm wondering if the barrier/invariant.group
>> is the right abstraction at all.  Are there other designs you
>> considered early on that we can revisit in the light of these issues?
>>
>> -- Sanjoy
>>
>
> I don't think there were any other ideas for propagation of the
> "invartianess" of the vptr -
> @Richard or @Nick, did you have any other ideas before my internship?
>
>
> I am open to hear any other ideas for the model - even if they would be
> not checked it might be a good inspiration.
> Right now the only problem with the current model for devirtualization
> (that we have seen) is the propagation
> of the pointers from comparision. It is also the problem that we knew
> almost from the beginning.
> @Sanjoy, maybe you have some ideas how the semantics of the
> !invariant.groups with propagation
> of the pointers could be specified in a way that it would not brake the
> testcases?
>
>
> Piotr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170523/9dfc329d/attachment.html>