[PATCH] D105407: [LangRef] Add elementtype attribute

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D105407#2860599 <https://reviews.llvm.org/D105407#2860599>, @nikic wrote:

> In D105407#2860515 <https://reviews.llvm.org/D105407#2860515>, @dblaikie wrote:
>
>> General thought: This seems unfortunately open-ended & could be used to used more generally in a way that might defeat some of the goals of the opaque pointers work (eg: if this gets added to arbitrary functions/used by transformations, etc).
>
> I think there's not a lot of danger of this being misused, at least in-tree, simply due to the fact that clang is not going to emit this attribute for normal pointer arguments. It's only going to be added by IRBuilder for some intrinsic calls, e.g. in IRBuilderBase::CreatePreserveArrayAccessIndex() .

Yeah, I was thinking more intentional - "oh, we have this attribute, we could start emitting it and using it in this other way" - at least documenting and constraining it in certain ways might provide someone a little more hesitation were they to think about using it for something else. Actually revisit the wording in the LangRef and have a design discussion about the new uses.

>> Could/should we limit this to only apply to intrinsics?
>
> That said, limiting it to intrinsics makes sense to me. For the future I have another possible use in mind with inlineasm+memsanitizer, but we can expand as needed later.
>
>> And can we possibly make it so this is not visible on the function decl, so transformations can't accidentally start depending on its presence (this attribute only really describes a feature of the implementation of the function, right? Not any requirement on callers about how they call such a function (they could pass in whatever pointer they like/doesn't really matter what it points to))
>
> Not sure I quite understand what you mean here. But if you're suggesting that this attribute should only be allowed on call arguments, but not on function parameters, then yes, that makes sense to me.

I was thinking the opposite, sort of - only on the function declaration, but if there was some way to make it so they wouldn't be readily observed by analysis/transformations, etc. Really the type is an implementation detail of the function, not part of its signature/not something callers should be observing/making choices based on, I think? But I doubt we have any infrastructure to provide that sort of private implementation detail property for an intrinsic.


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

https://reviews.llvm.org/D105407