[PATCH] D81311: [RFC] LangRef: Define inmem parameter attribute

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D81311#2088568 <https://reviews.llvm.org/D81311#2088568>, @jdoerfert wrote:

> In D81311#2088075 <https://reviews.llvm.org/D81311#2088075>, @rjmccall wrote:
>
> > In D81311#2087592 <https://reviews.llvm.org/D81311#2087592>, @jdoerfert wrote:
> >
> > > In D81311#2086326 <https://reviews.llvm.org/D81311#2086326>, @rjmccall wrote:
> > >
> > > > In D81311#2086227 <https://reviews.llvm.org/D81311#2086227>, @jdoerfert wrote:
> > > >
> > > > > Do we allow `inmem` to be used for other purposes? I would assume the answer is yes, as we do not forbid it.
> > > >
> > > >
> > > > I don't know what else we might use it for off-hand, but yes, I think the frontend could put this down on all value arguments that are actually passed indirectly.
> > >
> > >
> > > Where does it say it is limited to indirectly passed arguments?
> >
> >
> > The argument does have to be a pointer.  And passes aren't allowed to infer this or it becomes useless for the original purpose.
>
>
> That is what I'm trying to get at. As of right now, I don't see any reason a pass could not add this, or a front-end for that matter, for any call, assuming they now it won't mess with the ABI for the target. We might want to add language to this end?


But it does mess with the ABI; that's why it's being added.  All its optimization properties are redundant with existing attributes, and those attributes can't be used for Matt's purposes because he's rightly worried about them being inferred by passes.  This attribute specifically provides the extra information that this is semantically a value parameter being passed by reference, which can only be added by a frontend that has that information, which an ordinary LLVM pass cannot possibly have.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81311/new/

https://reviews.llvm.org/D81311