arsenm added a comment. In D79744#2030710 <https://reviews.llvm.org/D79744#2030710>, @rjmccall wrote:
> Okay. So the only real ABI here is the layout of the memory that the > arguments are actually written into? And that memory needs to be treated as > constant? Yes, the actual kernel ABI is supposed to invisible. > Unfortunately, I think `byval` just doesn't match what you want because of > the mutability — the frontend *has* to have a copy into a local to get IR > with correct semantics, because `byval` is assumed to be locally mutable by > both IR-generation and (potentially) LLVM optimization. And I don't think > you really want non-`byval` indirect. So I guess the question is what we can > do in the frontend to get the optimizer behavior you need. You are allowed to have readonly on a byval pointer argument, in which case optimizations wouldn't be allowed to write into it. Is just adding readonly parameter attributes sufficient? It would be somewhat contrived, but could also define byval as constant if it's not in the alloca address space. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D79744/new/ https://reviews.llvm.org/D79744 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
