rjmccall added a comment. In D79744#2035109 <https://reviews.llvm.org/D79744#2035109>, @arsenm wrote:
> 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. `byval` is fundamentally about expressing that something is passed on the stack. If you want an indirect readonly noalias argument, you can make one; however, to convince IRGen to do it, you really need to think of this as a new kind of argument-passing, because "pass the address of an immutable object that the callee can't modify" is not something that we normally need to do in calling-convention lowering. That feels like a lot of complexity to solve a rather narrow problem. A completely different approach: OpenMP has to solve some very similar problems and just lowers them completely in the frontend; have you considered just doing that? Kernels need a ton of special-case handling anyway, and IIUC you can never optimize over the boundary anyway. 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
