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

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 10 11:05:27 PDT 2020


arsenm added a comment.

In D81311#2084066 <https://reviews.llvm.org/D81311#2084066>, @rjmccall wrote:

> In D81311#2083295 <https://reviews.llvm.org/D81311#2083295>, @arsenm wrote:
>
> > In D81311#2078235 <https://reviews.llvm.org/D81311#2078235>, @rjmccall wrote:
> >
> > > I wonder if `byref` would be a better name for this, as a way to say that the object is semantically a direct argument that's being passed by implicit reference.
> >
> >
> > This is probably a better name, but potentially more easily confused with byval.
>
>
> That seems like an unlikely confusion.
>
> > As far as switching to just the raw number, I think there's value in being consistent with the other growing family of type-carrying parameter attributes but I don't really care about the type itself. I don't understand inalloca/preallocated well enough to know if those should also really only carry a size.
>
> I think carrying a type is probably an attempt to insulate them against the future removal of pointer element types.  I don't think it's actually necessary in either case and could certainly just be a size and alignment.  But if you want to use a type, I agree it's not inconsistent, and as long as you honor an explicit alignment it's fine.


The alignment is also technically a separate attribute and we generally don't require attributes to always be paired. I guess the verifier could require you to specify align if you use this, but that's another inconsistency


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

https://reviews.llvm.org/D81311





More information about the llvm-commits mailing list