[llvm-dev] Handling invariant.groups with equality + marking it as experimental

[Piotr Padlewski via llvm-dev]

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>