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

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D81311#2077944 <https://reviews.llvm.org/D81311#2077944>, @arsenm wrote:

> In D81311#2077868 <https://reviews.llvm.org/D81311#2077868>, @rjmccall wrote:
>
> > Most of the generalized optimization properties of this attribute seem to be redundant with existing attributes.  What are the properties you're trying to convey exactly?  The argument is a pointer to memory of a certain size and alignment, and that memory is known to be exclusive to this call and also constant?
>
>
> It's really just the in memory size and alignment. In this case, constantness is implicit since I'll use a constant address space for the pointer (and probably mark the parameter with readonly for good measure)


In principle, `readonly` has the same issues that lead to this attribute being necessary: it's not really a semantic contract, it's something that can be placed on the argument by IR.  But it's probably to separate that.

>> I don't think in practice those other attributes would ever not be preserved through IR passes, especially for kernels.  I guess they could be introduced by other analyses, and you wouldn't want this property to be confused with that?  Still, maybe it would be less redundant to just have this attribute require the existence of those other attributes (particularly `dereferenceable` and `align`) rather than providing its own structure.
> 
> I believe byval implies dereferencable already, and I was just trying to be more explicit than what the others state. The alignment behavior also matches what the other attributes already do. I expect in practice to always emit an align attribute

It's generally best to insist on strong rules up front and then weaken them if there's really a use case.  There's no good reason not to carry an alignment.

>> Do you actually need any of the structure of the type beyond a size and alignment?
> 
> Not really. I just need to distinguish whether you are are using sizeof(struct Foo) or a pointer sized slot in the argument buffer

Okay.  I think just carrying numbers is probably less representationally problematic.

My thinking here is that we can make this attribute something that we'd just add by default to all indirect arguments, and then the only special case behavior you need for kernels is that (1) there's a stable size and alignment that you can extract into the kernel-invocation system, which is probably not otherwise useful to IR beyond the existing attributes, and (2) the frontend needs to copy from the argument to form the mutable parameter variable.


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

https://reviews.llvm.org/D81311