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

Piotr Padlewski via llvm-dev llvm-dev at lists.llvm.org
Mon May 8 15:39:56 PDT 2017


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>


More information about the llvm-dev mailing list