arsenm added a comment. 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 caseonstantness is implicit since I'll use a constant address space for the pointer (and probably mark the parameter with readonly for good measure) > 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 > 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 CHANGES SINCE LAST ACTION https://reviews.llvm.org/D81311/new/ https://reviews.llvm.org/D81311 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
